X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/aebcbca4d620183d273736953da21ef05eb45e5c..63f09c7cef0eb10d8051a92ff626bf1b5f29b9b0:/doc/todo/blogging.mdwn diff --git a/doc/todo/blogging.mdwn b/doc/todo/blogging.mdwn index 1065a609a..f9037b063 100644 --- a/doc/todo/blogging.mdwn +++ b/doc/todo/blogging.mdwn @@ -1,4 +1,3 @@ -- 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 @@ -10,23 +9,23 @@ 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. +> 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. +> 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.. +> 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]] +> --[[Joey]] That's fair enough. I'm a little unsure of how it all works, so I just did the simplest thing I could. @@ -48,14 +47,14 @@ 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]] +> 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 @@ -69,21 +68,64 @@ that people wont use raw if they want to pod/vid/whatevercast? -- JamesWestby - Using File::Mimeinfo makes sense to me. +> 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. +> 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: - +> 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. :-) +> 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]] +> --[[Joey]] + +I tested with amarok, and that also ignored the description. +I am thinking of those where you have a mixed feed, and people +using clients that ignore enclsures get pretty much a blank post, +with just the filename, and the html page, which also just displays +the filename. + +I don't think this is a big issue though, so I guess it's just which +you think is the cleaner interface. + +I have also added the first of your ideas as well (though you seem to have +removed it). It adds a parameter to inline `archive_after` which limits +showing full entries to that number. + + + +-- JamesWestby + +> I removed it because I don't really see the need for it anymore. +> The added complexity doesn't seem worth it, unless someone needs the +> features. --[[Joey]] + +And here is the updated podcast patch supporting any file type. + + + +-- JamesWestby + +And here is a patch for the remaining item. It adds links to the bottom of +inlined entries for edit and discuss (if they are enabled). It doesn't add +links for edit if the filetype is not known. + +The stylesheet should probably be done slightly better than I have. I just +added a bit of spacing as the links were too close to the date. I have no +skill in this area though. Perhaps you would like to use the list system +that you have for the links at the top. + + + +-- JamesWestby + +> Thanks! I did tweak the css a bit. Not totally happy with it, but pretty +> good I think. (I'll try to get to the other patches soon.) --[[Joey]]