(NOTE: This is a draft, open for comments. Revision 2: 2004-10-11.)
In his post My message in a bottle to Bill Gates, Scoble talks about a new content ecosystem that includes Podcasting.
Well, yes, true, but what is (also) important is that this is all using standard infrastructure: HTTP(s), XML, RSS.
Especially RSS feeds using enclosures. Adam Curry has been talking about the beauty of enclosures for years. Why is it now all of a sudden taking off?
Because he found a killer app to drive it!
Podcasting takes this bit of basic infrastructure to the masses. (And it's happening very quickly.) That's great. And it is working well. Why? because we're using simple open standards, most of which have been around for many years.
Dave Slusher eloquently comments "The components are absolutely not novel, which is why it bugs me when I see people dismissing it on the basis that we've had the pieces for a long time. Well, yeah. The devil is in the details and the novelty is in the connections. What makes it different is the combination of the available files, the standardized packaging and the automated handling on the listener side - being able to approach something kind of like TiVo for audio. It's hard to overstate how much different it is when you connect up that last yard, and just check your iTunes or WMP to see what new things are waiting for you from your subscriptions versus having to go out and find them. It is the same difference as RSS aggregation to web browsing."
The beauty of such standards is that they can be used for many different applications. Podcasting is one such applications. It is currently the application that drives the acceptance of RSS with enclosures.
Dangers ahead
Podcasting is not the only application for RSS and enclosures. This should be kept in mind when working on the infrastructure. This means: if you're a developer working on a Podcasting client application be carefull that you don't create a method of using the infrastructure that limits its use for other applications.
Example: you decide to use the .podcast extension for rss files with enclosures. Podcasting publishers decide to use the .podcast extension for their Podcast feeds. Problem: publishers want to use the same feed for other types of content. '.podcast' in this case is confusing.
Extending the RSS + enclosure feeds for Podcasting only: It would be worse if the .podcast feeds contained some tag extension that breaks other applications.
This is a selection of the "choices" we have today for subscribing to weblogs:
(Don't whine about the doubles: ordinary users will ask you about the difference between the blue background rss 2.0 and the orange background rss 2.0.)
This is one example of where we've gone wrong already.
We now have the opportunity to do it again!
On a basic, infrastructure level the applications using RSS feeds with enclosures should behave the same. Based on the limited of knowledge I have now I would vote for adding one more standard component to the mix: a MIME type for rss feeds. (This has apparently already been discussed before, but the type is not listed on the IANA site.) The handler application should be smart enough to determine the kind of content of the feed: whether it only contains text or enclosures as well.
In his post My message in a bottle to Bill Gates, Scoble talks about a new content ecosystem that includes Podcasting.
Well, yes, true, but what is (also) important is that this is all using standard infrastructure: HTTP(s), XML, RSS.
Especially RSS feeds using enclosures. Adam Curry has been talking about the beauty of enclosures for years. Why is it now all of a sudden taking off?
Because he found a killer app to drive it!
Podcasting takes this bit of basic infrastructure to the masses. (And it's happening very quickly.) That's great. And it is working well. Why? because we're using simple open standards, most of which have been around for many years.
Dave Slusher eloquently comments "The components are absolutely not novel, which is why it bugs me when I see people dismissing it on the basis that we've had the pieces for a long time. Well, yeah. The devil is in the details and the novelty is in the connections. What makes it different is the combination of the available files, the standardized packaging and the automated handling on the listener side - being able to approach something kind of like TiVo for audio. It's hard to overstate how much different it is when you connect up that last yard, and just check your iTunes or WMP to see what new things are waiting for you from your subscriptions versus having to go out and find them. It is the same difference as RSS aggregation to web browsing."
The beauty of such standards is that they can be used for many different applications. Podcasting is one such applications. It is currently the application that drives the acceptance of RSS with enclosures.
Dangers ahead
Podcasting is not the only application for RSS and enclosures. This should be kept in mind when working on the infrastructure. This means: if you're a developer working on a Podcasting client application be carefull that you don't create a method of using the infrastructure that limits its use for other applications.
Example: you decide to use the .podcast extension for rss files with enclosures. Podcasting publishers decide to use the .podcast extension for their Podcast feeds. Problem: publishers want to use the same feed for other types of content. '.podcast' in this case is confusing.
Extending the RSS + enclosure feeds for Podcasting only: It would be worse if the .podcast feeds contained some tag extension that breaks other applications.
This is a selection of the "choices" we have today for subscribing to weblogs:
(Don't whine about the doubles: ordinary users will ask you about the difference between the blue background rss 2.0 and the orange background rss 2.0.)
This is one example of where we've gone wrong already.
We now have the opportunity to do it again!
On a basic, infrastructure level the applications using RSS feeds with enclosures should behave the same. Based on the limited of knowledge I have now I would vote for adding one more standard component to the mix: a MIME type for rss feeds. (This has apparently already been discussed before, but the type is not listed on the IANA site.) The handler application should be smart enough to determine the kind of content of the feed: whether it only contains text or enclosures as well.
i made a button/logo http://welchs21.spymac.net/podcastbuttonshort.gif i think we should have a standard button for podcasts....
Posted by: bryan | 2004.11.01 at 20:38