Plans for 'podcasting' (RSS file enclosures) and RSS-2 support
20-June-2005
permalink email thisWe've been asked several times about podcasting support out of knotes content, but so far have not had an opportunity to do anything about it. Frankly, until recently I was unconvinced about the power of podcasting. But for a while now I have been trying to get the point of it, and I guess I have (see for instance the recent news that the BBC is offering experimental podcasting feeds for some of its radio programming. It has also helped that Al Harris is working on a series of brief interviews on small enterprises and educational technology / open source software; these would make great audio feeds.
It has also occured to me that many of our users post a lot of documents (especially Mico=rosoft Word files :o) - podcasting in the sense of feeds with file enclosure information could be a great way to announce new documents and share them with subscribers.
OK. Sold. What kind of support should we offer? For a start, I do not think we need to proliferate yet another feed option in links from knotes pages. i think that enclosures should 'just work' by default in our feeds, if possible. Second, I do not think that editors should have to specify that an uploaded file should be made available through a feed - all files uploaded as attachment to weblog entries should by default be made available in the podcast feed.
We will be introducing RSS-2 feeds from knotes to support podcasting. We never intended to neglect RSS extension work in favour of atom, so RSS 2 support has been in our plans for ages. We may replace the existing RSS 1 feeds with RSS 2. We need to look hard at backwards-compatibility first; otherwise we will offer 3 feed types as salient links in weblog views: RSS 1, RSS 2 and atom.
We then have a thorny little issue to solve before it is straightforward for all attachments to be detected and added as enclosures. We want to solve this issue anyway for other reasons: at the moment attachments that come through API clients are stored in a weblog's/blog_mm folder, while attachments added through the web are stored directly within the weblog entry. The latter is the best way to treat attachments from the point of view of summarising and aggregating them as resources, and also for managin large numbers of them. the reason we stash attachments added through the API into blog_mm instead is that when the API gets the request to create an attachment the blog entry does not yet exist. We've considered a few hacks around this in the past but never had an urgent reason to do something about it. Now we do.
Watch this blog for news about the solution we come up with, and also for news about the RSS 2 feeds and podcasting.
Linking and trackbacks
When linking to this weblog entry, please use the 'permalink', which is http://www.knownet.com/Members/mmalloch/blog/entries/9650359746
