On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen <[EMAIL PROTECTED]> wrote:
This is misleading wording (and maybe part of the overall problem)!
Perhaps, but it describes one of the most important use-cases with feeds -- which won't be the one with entries.
Following a link is not the same thing as subscribing to something.
Of course not.
The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET.
Yep. But why would you do the GET in the first place? In what use case scenario would you put GET-ing an URI that returns an Atom Entry compared to one that returns an Atom Feed?
Your agent then decides if subscribing to that resource is a good idea.
How does it decide? By parsing the whole document first, e.g. content sniffing?
To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes <feed> or <entry>.
Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or even better; by the value in the @type attribute of whatever element referring to this resource, the client won't have to do a GET at all on resources it doesn't know how to handle properly. Most feed readers knows how to handle feeds, but have no idea how to handle entries.
When pointed at a URI they can say "Hey, I can't subscribe to this!" if the Content-Type is 'text/html', 'application/octet-stream' or whatever, but if the Content-Type is 'application/atom+xml', they think "Hey, this is a feed I can subscribe to!" and will in most cases fail because what they're trying to subscribe to isn't an Atom Feed but an Atom Entry.
Knowing before the GET whether the resource can be subscribed to (or whatever you may want to do with either entries or feeds separately) or not is useful information. And please note that "subscribe" is used here as a single use-case for the endless amounts of use-cases that will differ for Atom Feeds and Atom Entries.
Anyhow, why not monitor a single entry?
That's of course possible, but you will be monitoring indirectly if you're subscribing to a feed that has that entry and changes to that entry gets re-published to the same feed. However, that's not the issue at hand here.
I think this is far more a user agent configuration issue than it is a problem of the media type being returned.
I disagree.
FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal.
They are and they aren't. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
