On Dec 6, 2006, at 11:01 PM, Asbjørn Ulsberg wrote:
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.
Sorry, I do not understand what you mean.
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?
Again, sorry, I am unable to see what you are trying to tell me. Can
you explain?
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?
Not sniffing, but parsing. This would be done anyhow, no? You get
back a doc element object, look at the name of the root elemet and
dispatch.
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
Ok, HEAD would save the extra payload, but....I still think the
reason for subscribing is NOT how the representation at the other end
looks, it is based on the link semantics.
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.
This would be against Web arch: Content-Type is authoritative and can
well overide whatever the type attribute says or said a year ago.
Most feed readers knows how to handle feeds, but have no idea how
to handle entries.
So they should be fixed, should they not? They seem to only have
implemented half a media type.
When pointed at a URI they can say "Hey, I can't subscribe to this!"
What about chaging that to have them open a 'select plugin for this
media type' dialog? How come the desire for making the user agent
rely on a certain, rather limited circumstance (getting a <feed>).
Shouldn't Web agents be more actively-trying?
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!"
Then they implemented the RFC incorrectly I'd say.
and will in most cases fail because what they're trying to
subscribe to isn't an Atom Feed but an Atom Entry.
Again, why be so defensive? If your browser behaved like that you'd
kick it out (I'd do so at least).
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.
Ok, but it is simply not authoritative.
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.
That is one of the concerns I have: subscribing is just *one* use
case...and not even an Atom specific one.
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.
Then, in what sense are they not orthogonal???
[good discusion anyhow :-)]
Jan
--
Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»
