X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/5e7a3e74289248f464eb004b4e2176b27abe062e..bfe0d3f5c6671ccc26c510f5a07cc0deb926258d:/doc/todo/blogging.mdwn diff --git a/doc/todo/blogging.mdwn b/doc/todo/blogging.mdwn index 9ae6cf4a6..6ee9aaf5c 100644 --- a/doc/todo/blogging.mdwn +++ b/doc/todo/blogging.mdwn @@ -1,6 +1,89 @@ -- Add a small form at top and bottom of a blog to allow entering - a title for a new item, that goes to a template to create the new page. -- Should probably add params to control various rss fields like the blog - title, its author email, its copyright info, etc. -- The [[TODO]] page would work better if the first N were shown in full, - and then all open items were shown in summary. Maybe add this mode. \ No newline at end of file +- Add Discussion and Edit links at the bottom of each inlined post. +- It would be possible to support rss enclosures for eg, podcasts, pretty easily. + +Here is the last of those items. Using the meta plugin you can give the appropriate +info, and the enclosure will be added to the entry. It will also add a tag +at the top, but I don't know if this is necessary. It also includes a fix for +when make is used without PREFIX. + + + +-- JamesWestby + +> Hmm. Not quite how I'd envisioned podcasts would work, my idea was +> more that the sound files would be kept inside the wiki, and the +> inline plugin could be told to eg, inline *.mp3, and would add +> those to the rss feed as enclosures. Maybe you'd also inline some +> regular blog pages to describe the files or the like. + +> Do you think that would work or that it's worth pursuing that +> approach? I haven't looked at podcasts enough to know if that +> method would be technically feasable; for one thing it would limit +> the blog items for podcasts to just having an enclosure but no +> description. + +> Even if that doesn't work and pages are needed to desribe the items +> like you did, it still seems better to keep the podcast items in +> the wiki.. + +> --[[Joey]] + +That's fair enough. I'm a little unsure of how it all works, so I just did the +simplest thing I could. + +You don't need a description for podcasts it seems. So there's nothing stopping +you there. + +I have another patch that I think does what you want. It only supports .mp3 files, +.ogg or similar could be added easily. + +It has the disadvantage that the filename is all there is to go on, as I can't +think of a way to associate any information with the mp3 file. I don't +want to add a dependency on a IDv3 tag library. You could add another file +.mp3.info with the title/description in. + +It's obviously up to you which way you want to go. + + + +-- JamesWestby + +> Hmm, this could be taken a step further, and assume that if +> IkiWiki::pagetype doesn't return a defined page type for the page +> in the blog, then no matter the extension it should be fed into the +> rss feed in an enclosure. This would allow for not only podcasting, +> but vidcasting and a form of photo blogging. Or even an rss feed +> containing the source of ikiwiki. ;-) +> +> --[[Joey]] + +Yes I agree that this would be great, but rss2 spec says that enclosure +must have mime-type. How about I use the File::MimeInfo trick from the +first patch to do this? I don't know why I didn't do this before. +This will probably clean the code up a little as well. + +What do you think of the change that when using raw, if the filetype is not +known it adds an entry anyway? I did this so that the entries appear if +this mode is used. It might be that this is not necessary, as can we assume +that people wont use raw if they want to pod/vid/whatevercast? + +-- JamesWestby + +> Using File::Mimeinfo makes sense to me. + +> I think it probably makes sense to make the (html) blog page +> add an entry with a link to the file that's in the enclosure in the +> rss feed. Whether or not raw is being used. + +> Note: I'm still unsure about whether podcasts should support +> descriptions for the enclosures or not. Here's an early podcast +> that did use descriptions: +> +> Here's a contemporary podcast, which also uses descriptions: +> + +> The podcast client I use certianly doesn't care about the +> descriptions. But it's podracer, probably not the thing most +> podcast users use. :-) + +> --[[Joey]]