(should probably split this page ... later) See also EasySubscribe, RssAutoDiscovery
Feed autodiscovery
If Atom is going to be the name, I suggest we create a new MimeType for it and use this sort of LinkTag in the head for Atom Feed autodiscovery:
<link rel="alternate" type="application/atom+xml" title="Atom feed" href="http://full/url/of/atom/feed" />
Feed autodiscovery Discussion
Is this going to be included in the specification? How about autodiscovery of multiple feeds (PartialFeed, CompleteTextFeeds etc)?
[PhilWolff] See autodiscovery of new extensions in a ComponentBlog.
"Maybe RSS Autodiscovery Should Change (in Echo)?"
[DannyAyers RefactorOk] There's also Foaf and potentially many other kinds of AutoDiscovery to consider too. It might be worth having a look at how this kind of thing's done in RDDL, in particular CommonlyDefinedLinkPurposes.
[AsbjornUlsberg] I totally agree, Danny. As I write below, I don't think the <link> will suffice. We need more, although a <link> in an (X)HTML file is of course a nice substitute for the lazy ones.
See also : ExtraInterop or SyntaxExtensionMechanism
API autodiscovery
Previous suggestion was to use a LINK tag pointing to an RSD file pointing to an introspection file. Multiple people have pointed out that this is too many layers of indirection. Recommend we simply use a LINK tag pointing directly to the introspection file.
[DanielBerlinger] The arguments for using RSD are that it is a deployed format (don't underestimate the importance of this) that can contain all the facets of the introspection file. There was never any reason for an RSD file to point to another file. An informal poll taken on the Atom-syntax mail list seemed to lean in favor of using RSD although this has not been reflected anywhere else to my knowledge. The concerns regarding "ownership" of the current spec have been addressed in that I'm willing to release the RSD spec under an open license supported by community concensus, the format, as always, is completely open.
References:
-
[DareObasanjo] Comments on Atom API draft 6 "Too much indirection when attempting to discover information about the services a site supports. I have to hit the website's homepage which has a LINK element which points to an RSD file which to an introspection file that describes the features supported by the website before I can figure out which Atom API services teh website supports. At least one of those steps is unnecessary. I don't see why the link element can't directly point to the introspection file."
[AsbjornUlsberg] I think we should standardize an URI which points to a discovery file, like e.g. "http://example.com/api.echo". Some of the work done on UDDI might also be used. I think it's dumb to rely descovery upon potentially non-valid HTML. It's better to describe the whole website (with it's users and their echo feeds, etc.) in an XML file which has a standard URI. If websites don't provide this XML file, discovery must be done through other mechanisms, but I don't think it's necessary for the Atom project to provide other mechanisms than this one discovery file.