Mark Nottingham wrote:
Well, there will always be different buttons, depending on the software on the other end; I never bought into the "XML" button concept; standardizing UI for these things is generally bad.
With that kind of thinking we never would have gotten the general purpose UI that goes under the name Web Browsers.
Well I'm a bit beyond my deapth here, but here goes anyway. How about a combination of a <a href="foo?action=subscribe&feed=bar">common button</a> and a user preference selection at a web site. Then foo is the URI of a script that interacts with a user preference for a specific local or golbal resource. The script page would display a simple selection of known aggregators and the user simply selects the radio button and the resultant post is to the local or global resource. The foo could be common to all blogs, so that the user's preference for foo could be kept in their cookie and a user would need to select it only once. Whould that work?However, the means of marking up a document so that the button gets put there (somewhere) - that MUST be generic, to avoid separate buttons for different clients *unless* the end user wants to use multiple clients. The "Internet" way to do this is to use a media type in the HTTP Content-Type header (and maybe a 'type' hint on 'a' and 'link' links) to dispatch to the appropriate software; so, when a browser sees Content-Type: application/rss+xml it knows to send it to the aggregator that the user has configured. The problem here is that some aggregators aren't local software; they live on the Web at other URIs. Unfortunately, I don't know of any browsers that allow Content-Type dispatch to another URI; I have logged a bug [1] with Mozilla. As far as how this shows up in the browser; it depends. A <link> tag will show up in Mozilla in the menus; other browsers can follow suit, or come up with something else. Failing that, a good, old <a href="..."> will do the trick.
Seth Russell