A. Pagaltzis wrote:
window. This works very well when the links are to web pages or
other resources that can be handled usefully by a browser, but
it's a complete waste of time if the link is pointing to an
Atom feed.
You do that even if it’s
<link rel="related" type="application/atom+xml" href="..." />
Ideally if I know the type I can try to subscribe immediately without going
through the browser which is likely to fail. My assumption (at least up to
now) was that if a feed producer was adding a related link to another Atom
feed it was because that feed really was a relevant, related link. However
this extension is encouraging the feed producer to include related links
that I don't think are very useful to the user and that they wouldn't
usually include.
It makes perfect sense when you think about it theoretically. Those
documents are technically related. But when you think about the practical
implications, how the client needs to deal with it, how it affects the end
user, I don't think it's a good idea.
Minimally, it can pull the feed and look for its alternate link.
Less minimally it can also look at all the other metadata that
Atom documents can contain.
We’re talking about an Atom consumer here; that it wouldn’t be
able to do something sensible with Atom docs strikes me as an odd
objection.
That's possible, but definately not something I would consider doing. Right
now when a user clicks on a link I can pass that link directly to a browser.
You're suggesting I should check the link type (possibly by doing a HEAD)
and then if it's an Atom document I download the document myself, parse out
an alternate link and then pass that on to the browser. I'd prefer something
a little more efficient than that for a simple link click.
But I guess that is a possible alternative. Do you know of any client
implementations that do that sort of thing?
Regards
James
