Regarding Dave Winer’s idea for some form of centralized syndication feed system, I got a chuckle out of the comment, “What problem am I having and how is a centralized service going to help?” in Phil Ringalda’s post Centralized Subscription? Not that way thanks. You see now the great benefit of being exposed to us techs through weblogging: you get to experience, with us, the joy of uncertainty that comes from knowing that you’re always on the edge of failure.
Dave does have a point in that if you provide one click subscriptions for one aggregator, such as a Subscribe via Bloglines button, it won’t work for other aggregators; you either have to blow off the others, or you end up with a trail of buttons down your page, like stepping stones across a vast sea of syndication.
You could be like me, and provide the bare minimum to aid in subscription: auto-discovery enabled via my weblog tool, and a couple of links to feeds in my sidebar. However, I will be the first to admit that clicking a link to open an XML file isn’t the friendliest way to get people to subscribe to your site’s syndication feeds.
I am open to alternatives to this arrangement, but not necessarily Dave’s approach. Though he hastens to say that his approach isn’t a centralized directory, it is a centralized source of data, one with consequences beyond the intended purpose.
Dave’s solution would require that you pass to the service a link to an OPML file, which contains a listing of sites to which you subscribe, and then click a link to add a new subscription. In return the service would provide the list in a format specific to whatever aggregator you use. Your subscription list would then be merged with other subscription lists, and made public; the data contained being accessible for other purposes.
With this approach, not only would I be able to more easily subscribe to your writing, I could also take a look at who you read, and don’t read. Would your subscription list be the same as your blogroll? If not, are you prepared to answer questions from those who you link to, but don’t read? How about those who you read, but don’t link? I could even use your subscription list as my own, so that I can read the exact same sites you read every day; more, I could follow you around in comments, adding my own following yours, just to let you know I’m near and thinking of you.
Phil wrote his own scenario, about subscribing to a site that provides information about spastic colons, which can then get Googled by the hot new love of your life. We say we’re an open book, but do we really want to be that open?
As Phil demonstrates so effectively, which service works best is the one that requires the minimum of information. This follows from a known paradigm in designing relational databases or class systems in languages such as PHP–more data is more overhead and increased complexity, so you keep the data needs as simple and specific to the problem being solved, as possible.
In fact, though the needs of aggregation aren’t the same as identity, we could apply Kim Cameron’s second law of identity, the Law of Minimal Disclosure, to this problem: The solution which discloses the least identifying information is the most stable, long-term solution.
In the case of too many subscription buttons, Phil recommends the Syndication Subscription Service, as a solution. The service doesn’t require anything more than a link to your syndication feed, and when accessed, returns a set of buttons for many different aggregators. In fact, I liked this service so much that I’ve pulled my links to my two Atom and RDF feeds in the sidebar and replaced them with a link to it, instead.
Though it is also a centralized service, it’s one that requires a minimum of data and effort, and since the code to support it is open source, could be duplicated if need be. Best of all, it’s something I can use now for this newly discovered problem I didn’t know I had, but which has now been solved, and so no longer exists.
Much of the discussion is about handling feeds like audio files, and the so-called feed protocol. I like what Seth Dillingham wrote on this long ago:
The feed protocol was originally designed for farms. Cattle, for example, just have to click a button to access a feed: url on the farmer’s server, which causes grain to be dropped in the trough.
In a bizarre misuse of this important technology, the feed protocol can also be used to request an RSS or Atom file, to “feed your brain.”
I’m with the cows on this one — if I can’t poke a button with my nose and have it give me food right now, I’m moving to a different barn.
