1- It would be possible to support rss enclosures for eg, podcasts, pretty easily. 2 3Here is the last of those items. Using the meta plugin you can give the appropriate 4info, and the enclosure will be added to the entry. It will also add a <link /> tag 5at the top, but I don't know if this is necessary. It also includes a fix for 6when make is used without PREFIX. 7 8<http://jameswestby.net/scratch/podcast.diff> 9 10-- JamesWestby 11 12> Hmm. Not quite how I'd envisioned podcasts would work, my idea was 13> more that the sound files would be kept inside the wiki, and the 14> inline plugin could be told to eg, inline *.mp3, and would add 15> those to the rss feed as enclosures. Maybe you'd also inline some 16> regular blog pages to describe the files or the like. 17 18> Do you think that would work or that it's worth pursuing that 19> approach? I haven't looked at podcasts enough to know if that 20> method would be technically feasable; for one thing it would limit 21> the blog items for podcasts to just having an enclosure but no 22> description. 23 24> Even if that doesn't work and pages are needed to desribe the items 25> like you did, it still seems better to keep the podcast items in 26> the wiki.. 27 28> --[[Joey]] 29 30That's fair enough. I'm a little unsure of how it all works, so I just did the 31simplest thing I could. 32 33You don't need a description for podcasts it seems. So there's nothing stopping 34you there. 35 36I have another patch that I think does what you want. It only supports .mp3 files, 37.ogg or similar could be added easily. 38 39It has the disadvantage that the filename is all there is to go on, as I can't 40think of a way to associate any information with the mp3 file. I don't 41want to add a dependency on a IDv3 tag library. You could add another file 42.mp3.info with the title/description in. 43 44It's obviously up to you which way you want to go. 45 46<http://jameswestby.net/scratch/podcast2.diff> 47 48-- JamesWestby 49 50> Hmm, this could be taken a step further, and assume that if 51> IkiWiki::pagetype doesn't return a defined page type for the page 52> in the blog, then no matter the extension it should be fed into the 53> rss feed in an enclosure. This would allow for not only podcasting, 54> but vidcasting and a form of photo blogging. Or even an rss feed 55> containing the source of ikiwiki. ;-) 56> 57> --[[Joey]] 58 59Yes I agree that this would be great, but rss2 spec says that enclosure 60must have mime-type. How about I use the File::MimeInfo trick from the 61first patch to do this? I don't know why I didn't do this before. 62This will probably clean the code up a little as well. 63 64What do you think of the change that when using raw, if the filetype is not 65known it adds an entry anyway? I did this so that the entries appear if 66this mode is used. It might be that this is not necessary, as can we assume 67that people wont use raw if they want to pod/vid/whatevercast? 68 69-- JamesWestby 70 71> Using File::Mimeinfo makes sense to me. 72 73> I think it probably makes sense to make the (html) blog page 74> add an entry with a link to the file that's in the enclosure in the 75> rss feed. Whether or not raw is being used. 76 77> Note: I'm still unsure about whether podcasts should support 78> descriptions for the enclosures or not. Here's an early podcast 79> that did use descriptions: 80> <http://static.userland.com/gems/backend/gratefulDead.xml> 81> Here's a contemporary podcast, which also uses descriptions: 82> <http://www.lugradio.org/episodes.rss> 83 84> The podcast client I use certianly doesn't care about the 85> descriptions. But it's podracer, probably not the thing most 86> podcast users use. :-) 87 88> --[[Joey]] 89 90I tested with amarok, and that also ignored the description. 91I am thinking of those where you have a mixed feed, and people 92using clients that ignore enclsures get pretty much a blank post, 93with just the filename, and the html page, which also just displays 94the filename. 95 96I don't think this is a big issue though, so I guess it's just which 97you think is the cleaner interface. 98 99I have also added the first of your ideas as well (though you seem to have 100removed it). It adds a parameter to inline `archive_after` which limits 101showing full entries to that number. 102 103<http://jameswestby.net/scratch/limit.diff> 104 105-- JamesWestby 106 107> I removed it because I don't really see the need for it anymore. 108> The added complexity doesn't seem worth it, unless someone needs the 109> features. --[[Joey]] 110 111And here is the updated podcast patch supporting any file type. 112 113<http://jameswestby.net/scratch/podcast2.diff> 114 115-- JamesWestby 116 117And here is a patch for the remaining item. It adds links to the bottom of 118inlined entries for edit and discuss (if they are enabled). It doesn't add 119links for edit if the filetype is not known. 120 121The stylesheet should probably be done slightly better than I have. I just 122added a bit of spacing as the links were too close to the date. I have no 123skill in this area though. Perhaps you would like to use the list system 124that you have for the links at the top. 125 126<http://jameswestby.net/scratch/actions.diff> 127 128-- JamesWestby 129 130> Thanks! I did tweak the css a bit. Not totally happy with it, but pretty 131> good I think. (I'll try to get to the other patches soon.) --[[Joey]] 132 133 134--- 135 136I'm very happy to report that this is [[todo/done]]. Podcasting patch 137applied (finally!) --[[Joey]] 138