Syndication Formats are your friend
Why do you subscribe to blogs? Because all of your friends do, and you don't want to be singled out and have your underwear pulled over your head? While we all want to avoid the metaphorical tech wedgie, most of us subscribe to blogs because we want an easy, consistent way to have information come to us.
This idea in itself is pretty important. Most of the time the information that comes to us is about cheap Viagra, how to lower our mortgages, and Rolex watches. Unless you are an impotent low wage earner in need of some bling, you need a better way to get information about what you are interested in. This is where syndication formats such as RSS or ATOM come in. You subscribe to feeds that interest you and your aggregator of choice brings the content to you.
Syndication formats provide a simple way for content producers to publish their content and an easy and convenient way for consumers to receive the content. This has been the foundation of the success blogs have had. With the advent of enclosures, feeds can provide not only textual information, but also binary content. With smart aggregators, large binary content can be downloaded to your local machine in a time-shifted manner and executed at your convenience.
PodCasting and the blogosphere
Rory Blyth recently posted an excellent blog on PodCasting and its advantages as a distribution method.
As a content consumer he makes the following arguments for PodCasting:
- PodCasting is a distribution method consistent with how users are getting content/music elsewhere
- Syndication formats free the user from having to worry about how to get to the content
- PodCasting empowers content producers, no more record label, just need a web server
- PodCasting, then, is convenience for users. Idea is the content you want is coming to you instead of you to it.
- PodCasting is a just means of syndicating binary content.
- PodCasting is serious Power to the People technology
Carl Franklin, Rory's partner in crime, has also posted on PodCasting as a productive medium for content producers. If you don't know who Carl is, he is the host of a hugely popular internet audio show called .NET Rocks!
As a content producer he makes the following arguments for PodCasting:
- Think about PodCasting as a publishing process or a new form of media
- It's about pushing only the stuff that the customer wants, and filtering out the unwanted stuff
- All sorts of really niche shows will pop up
- Someday soon perhaps be the foundation on which audio and video media, and perhaps even software
My take on PodCasting
Seeing the PodCasting phenomenon and not wanting to be left out, I installed iPodder but found it didn't match my anal retentive personality enough and now am using Doppler. The point is to get an aggregator that can handle enclosures in a smart way. I think we will be seeing all of the popular aggregators support enclosures in the near future. And you can always write your own aggregator if none of those meet your needs.
I LOVE PodCasting. Instead of spending a hour reading all of the blogs I am subscribed to I know spend an hour reading all of the blogs I am subscribed to, and then listen to the audio content I am subscribed to while coding. I currently only listen to .NET Rocks! and BlogoSphere Radio but don't be fooled by the small content base available right now, this is an idea with legs. I used to check a few audio sites every day, download the mp3/wma file(s), then listen. Not only does PodCasting make my life a hell of a lot easier, it makes me more inclined to listen to a larger variety of audio content that I normally wouldn't bother with. As a content producer this should make you VERY happy. By providing your content in a form consumable by aggregators, you will greatly increase your consumer base. As Rory said, "PodCasting is serious Power to the People technology".
My top petty grips about PodCasting:
- The name. PodCasting in my mind is strongly linked to just audio. Enclosures can be so much more! Enclosures handle any BINARY information, and does not need to be limited to just audio codecs. If PodCasting remains only a distribution model for audio, I think we will have failed.
- Lack of aggregator support. I use SharpReader as my feed aggregator. I use Doppler as my PodCasting aggregator. Give me one aggregator that handles both. PodCasting is very young, and I expect market/consumer pressure to fix this quickly. And as a geek, if I don't like it, I can write my own aggregator. So I will stop bitching now.
- Searching for PodCasts. Again, PodCasting is young. Most PodCasts I find are through link lists on specific audio sites. We need a Google for PodCasts. Once there is critical mass, someone, maybe even Google, will provide consumers with a search engine that allows us to find content in a very granular way. This brings to mind Scoble's post on Connectors vs. Commentators
ByteCasting: Taking enclosures to the next level
Letting the aggregator do the work: Have you ever utilized a piece of code from SourceForge? You find some useful piece of code, download version 0.4.3 of the binary. On some projects the version can change every week. Do any of us want to manually check for a new version? I don't. Imagine if there was an RSS feed for each project that had enclosures referencing each new build revision. There could also be developer notes, bug fix details, supported platforms, and all of the other information you often see. Subscribing to this feed would at the very least remove the need for me to do it, or more likely forget to check for a new version. Ideally it would also keep me informed of bugs, available workarounds and patches, as well as progress on the project. Many companies have their build process blog the results of daily builds and the results of test passes, so that each morning you find out what you broke while you were coding and drinking scotch. With enclosures, your feed could not only provide information on the build, but also point to the project output(s). For windows applications, this could mean your test team comes in, and their aggregator has already pulled down the latest build to their machine so that they can begin testing.
Software library distribution: I currently have an MSDN universal subscription. For those not in the know, this means I can download damn near every Microsoft product I could possibly need. There are literally hundreds of ISO files or executables I can get. Some of these are used by not just me, but other people in my IT department. Currently I have a 200GB+ directory on our SAN that holds all of the software we are licensed to use, as well as other open source tools and utilities. I had been meaning to write a n-tier web or smart client application to provide an easy means of searching and finding software and installing it, along with the product keys needed to active the product and any related service packs or add-ons. With RSS and enclosures, I can instead just generate a feed for the available products and their associated files. With a little work I could even write an aggregator that notifies users of when a new version is available from MSDN, and I could leverage the MSDN subscription feeds to download MSDN products to the main data store (theoretically).
ByteCasting challenges: PodCasting is an excellent syndication format for getting freely available audio content to interested consumers. ByteCasting could be an excellent syndication format for getting binary/executable content to consumers. But how do we handle content that is available only to those who have purchased it? How do we handle access control? While ACLs might work for Windows platforms, it may not be appropriate for internet based solutions. These sort of questions make me wonder if RSS enclosures are the appropriate syndication format, or that we need to extend enclosures to handle security needs. One idea I had as an example solution:
- Consumer is granted access/purchases a product
- Producer generates a public/private key pair unique to consumer
- Producer provides consumer with private key and URI to feed that references subscriber ID (www.foo.com/products/rss.aspx?ID=a123b567)
- Consumer can now pull content from feed, and aggregator uses private key to decrypt content that was encrypted by public key. Producer is responsible for encrypting enslosure content, aggregator responsible for decryption.
- Summary: Either RSS enclosures need to be extended to handle the PKI problem, or we leave it to producers to provide customized aggregators. Ideas?
Please let me know if there are better solutions, or if you have a better idea. The basic problem that needs to be solved is that a publicly available feed's enclosure content needs to be limited to valid consumers.
PodCasting Resources