On Nov 21, 2004, at 1:49 PM, Bill Kearney wrote:
I'd wonder if calling the latter anything with the word "Feed" in it isn't
more trouble than it's worth?
I'm flexible on terminology, as long as it makes sense (Walter had some proposals).
When you get a Feed Resource, it contains a [EMAIL PROTECTED]'this']/@href that points to the Atom Document Resource for this particular Feed Document;
Being required or optional?
Optional; the proposal makes this a SHOULD.
Oh you ARE the optimist aren't you? I do like the idea you're suggesting
but it sort of seems like a lot to ask. Just getting developers to break
out of the "one GET to feed it ALL" will be a challenge. Asking them to
walk over prev links, while a good idea, seems pretty unlikely. I'd favor
use of some sort of 'range' options over the prev/next idea. It feels like
more developers would grasp the latter instead of multiple calls traversing
it backwards. That and I can envision source providers being more inclined
to allow range retrieval much more readily that some sort of manifest of
feed entry 'groupings' that would use prev/next.
GETting multiple resources' representations didn't stop the IMG tag from taking off in HTML, and I don't see how it's a significant challenge here. Rather than presupposing what developers are going to do, I'd rather get feedback from those people directly.
I don't dispute that this calls for some (manageable) work on the client side. I think that is vastly preferable to requiring support for query on the server side; there will be many more feeds than aggregators, if Atom is successful.
BTW, are you proposing that every request to the server for the feed's state is a query? Otherwise, I don't see how you can avoid multiple requests when reconstructing feed state (one to get the latest entries, at least one to get the entries you missed).
I'm not sure
I could see individual sites bothering to do this or benefitting from it
even if they did.
If I publish a feed, I want my consumers to see the entire information channel, not portions of it. That's a huge benefit.
For example, if you have a completely database-driven feed, and your
exposed Atom feed document contains 10 entries, and you've published
1000 entries in total, the 'this' URI in your most recent Atom Document
might be 'http://www.example.com/feeddb?entries=990-1000', and the
'prev' URI might be 'http://www.example.com/feeddb?entries=979-989'.
That document, in turn, would be returned with a 'prev' URI of
'http://www.example.com/feeddb?entries=968-978' (You could, of course,
overlap them too, if you want to).
Hmmm, I start getting worried when I see parameters in URLs and how their
semantics might be 'assumed' by folks. Just as dates or integers in
namespace URI aren't versions. Not to mention i18n issues of calling them
'entries' in a URL. If you want to publish metadata then do so without
requiring special knowledge in a URL.
Perhaps you've misunderstood the proposal. It does not break URI opacity; the client is not required or encouraged to interpret the semantics of the URI; it's only interpreted by the server (the same party that issues it). This has the benefit that from the server side, it can be used as a query function if necessary, but the client doesn't need to understand the query's semantics, and, more importantly, no standardisation of query semantics is necessary.
I'd wonder how the requesting client would know how many it includes?
Why does it need to?
Hopefully, this mail will help.
Yes, somewhat. I now understand you're talking about two different things.
One being a feed of entries and the other being a way to extract a wider
range of entries. I can see what you're trying to accomplish.
I wonder; I'm not sure how to interpret that explanation.
I'd be more inclined to want some sort of query semantics that let me ask
the site what ways it offers for obtaining 'back content'. And then using
those semantics to request manifests of the entries for subsequent
retrieval. If a site has tracked them in groups of previous feed
publications then fine. But I'd also like to have the ability to do better
range requesting, most probably by timestamp but I'd sure others might want
something different.
Imagine, rather than just http for prev how about torrent or ed2k requests?
Or redirection to an archiving service or 'nearer' data store?
You clearly would like to do many ambitious things with Atom. That's great, but we need to be realistic about what we can do in this effort while still differentiating Atom from RSS.
Both of these approaches can satisfy the requirement to reconstruct a feed's state. The design I've proposed is simple, robust, leverages the Web and delivers needed functionality quickly; looking at similar efforts in the past (SQL, XML Query, RDF Query, conneg, etc.), we can reasonably expect that getting query right is going to take a long time and a fair amount of iteration, and it's going to be much more complex.
Thanks,
-- Mark Nottingham http://www.mnot.net/
