--- Neil <[EMAIL PROTECTED]> wrote: > Here's a more complete answer that Phil Ringnalda gave me: > > feed: URIs started to solve two problems - that a link to a feed just > showed "an incomprehensible spew of XML" to people who clicked on it > without a handler installed for the mimetype (in the rare case where the > mimetype was anything even vaguely right, since only Atom has a > registered mimetype and most RSS is served with something random and > utterly wrong, like text/plain or text/html), and that even if you have > a feed reader installed that's registered as a handler for some > IETF-unregistered and unregisterable type like application/rss+xml, > content-type handlers don't get the URI, they get a local copy of the > contents, and RSS doesn't have an element whose contents are "the URL > for me." So in the days before any browsers recognized and did anything > with feeds, linking to feed://example.org/myfeed/ instead of > http://example.org/myfeed/ would let feed readers that knew to register > a handler for feed: successfully subscribe, since they would get the > URI, and would tell people without one that there was no point in > clicking the link. > > Of course inventing a non-protocol protocol because people don't use > mimetypes properly, and because you don't like the content of your > format, is completely contrary to WebArch and it will never be > registered and really shouldn't have been done, but it's done and in the > wild. Whether or not it currently does I don't know, but for several > years the default feed links in WordPress were feed: URIs, so there are > several million links with @href starting feed:// on the web. > > Then the oddly named version of Safari named for a single feature, > Safari RSS, added sniffing of feeds, and they appear (from the outside, > I haven't looked at their code) to have decided it would be handy to use > feed: URIs both internally, to tell that they'd sniffed a feed, and > externally, in the URI they pass to a client app if you are using > something other than Safari as a feed reader, so that if you click on a > link to http://blog.mozilla.com/feed/ in Safari, it will either display > feed://blog.mozilla.com/feed/ as the URI for its internal feed reader > display, or it will send feed://blog.mozilla.com/feed/ to your default > feed reader. > > That put Fx2 in the position of needing to do two things with feed:. > First, to be able to send both feed://blog.mozilla.com/feed/ and > http://blog.mozilla.com/feed/ to the same place, either your one true > feed reader or the preview page so you could decide where to send it, it > needed to handle feed: internally, and ignore any attempt by outside > apps to register for it, and second, to deal with the situation Safari > had produced on OS X (according to beng's comment in the code, I've > never tested), it needed to pass feed: URIs to client apps there, since > that was all they expected to get from a browser. So as far as Firefox > is concerned, feed://foo and http://foo with something sniffable as a > feed are the same thing, application/vnd.mozilla.maybe.feed until it > knows whether or not it can parse it as a feed, then if it can't both > are http://foo, but if it can both are feed://foo, since once this > year's version of Outlook came out only accepting feed subscriptions > with feed: URIs, not with http: URIs, I decided it was simpler to just > pass feed: URIs to local apps on all platforms, so (unless I get backed > out in the next few months) Fx3 is going to do that.
Wow. What a mess. I did see the comments he refers to here: http://mxr.mozilla.org/mozilla1.8/source/browser/components/feeds/src/FeedConverter.js#373 and wondered about them, not having used a Mac this decade. Anyway, thanks for sharing. Eric _______________________________________________ Project_owners mailing list [email protected] https://www.mozdev.org/mailman/listinfo/project_owners
