[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen
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
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>
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.
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
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»