Here’s a fun idea, a generalization of MIME types.
As a prolog let’s look as details of one of two one-click subscription solutions mentioned in the prior posting. The one that avoids a central hub/server but instead requires that we do some rework on all the clients. That cost got me thinking about how to pack more value into the rework.
In the blog subscription scenario the blog offers a “subscribe now!” button. Clicking it sends to their browser/reader a document which the browser/reader reacts to by creating a subscription. That action is triggered by the MIME type of the document. In Tim’s scenario MIME type is application/atom+xml.
If your managing your blog feeds using a local news reader as I am (e.g. NetNewsWire) then it’s an easy matter for the reader to register as the handler for that MIME type. Things are a bit harder if your new’s reader a web site, for example BlogLines. In that case you need to install something that catches incoming documents of this MIME type and turns around and hands them off to the web site.
Can we generalize this idea? Certainly. How much value can we pack in this subscription offer MIME type?
A simple step up in the idea is to create a MIME type document bouncer. An application you install on your machine and when a document of a given mime type is received or opened it turns around and redirects that document off to helpful website. For example such a beast could help users view documents that aren’t widely supported. There are plenty of these! This would useful.
A nice improvement on that would be to provide a way that helpful websites could plug into this easily. For example. Bob implement a service that can convert documents of MIME type ‘application/powerpoint’ into other formats – for example SVG, Open Office, etc. Bob’s website is a pain to use. Bob needs a way to tell the document bouncing application about his service. So he adds “Add Converter” button his site. Should the user click that a document sent to the user’s reader/browser (might have the type application/dispatch-offer). That gets handed off to the document bouncer which update’s it’s dispatch-tables/pattern-matchers and next time a document of type application/powerpoint come over the threshold it can offer our happy user the option of the document to Bob’s conversion service.
In my fantasy this can get even cooler. Going back to the blog example. The blogs provide a ‘Subscribe!’ button, the document that returns can describe a number a means of subscribing – email, rss, atom, whatever. The new reader(s) can place a number of patterns into the dispatch negotiation program. After hitting the subscribe button the user is presented with a menu of choices. He that allows him to route the subscription offer to the handler that is appropriate for the blog in question. He can redirect the subscribe offer to BlogLines, NetNewsWire, depending on what fits the situation.
One last step. The data feeds from blogs are just the tip of the iceberg. For example all my financial institutions have data that I pull down from them in service of keeping my financial house in order. Each one of these ought to, but doesn’t, have a “get data feed” button. Stitching up the links, for example passing those links thru to my accountant, is a huge plumbing problem.
It’s a fun idea that we might be able to create a very general scheme that allows data providers to describe what they have to offer – a set of choices – in a single document. It’s also a fun idea that data consumers could describe what they offer to handle. Giving the the offer to provide, and offer to handle a MIME type and a manager that the user controls we can keep the user control of making these linkages, where he belongs, while making the user’s experience tractable.