Mark Nottingham wrote:
Hi James,
On 29/06/2005, at 10:09 AM, James M Snell wrote:
1. This appears to be addressed at solving the same problem as Bob
Wyman's RFC3229+feed proposal [http://bobwyman.pubsub.com/main/
2004/09/using_rfc3229_w.html]. Do you have any empiracle data
similar to what Bob provides @ http://bobwyman.pubsub.com/main/
2004/10/massive_bandwid.html that would indicate that your approach
is a better solution to this problem? These are actually not
mutually exclusive solutions, they're just different and could be
used for different scenarios -- e.g. Bob's tends to make a lot of
sense for blog dashboard feeds like what we use within IBM to show
all post and commenting activity within our internal blogs server
while your mechanism would work rather well for things like Top Ten
lists, etc. I would just like to see a bit of a compare/contrast on
the two approaches.
It's orthoganal to RFC3229. The problem I'm solving is how to
reconstruct the *entire* state of the logical feed, not just one
partial representation of it; although RFC3229 could be used to do
that, it would require feed authors to post the entire content of
their feed (potentially, many megabytes). This would incur a huge
load, because any clients that don't support RFC3229 would have to
GET the entire feed, leading to severe bandwidth problems.
To give a concrete example, Dave Winer would have to post one RSS
file containing every entry he's made in Scripting News for the past
10+ years to use RFC3229 to meet the same goal; with this proposal,
he'd just have to add a 'prev' to each archived feed (assuming he has
archives around, which if he doesn't, I imagine he could reconstruct).
At times we do get spolied by the ability to dynamically generate
responses don't we ;-) You're obviously correct when it comes to
statically generated content - RFC3229+feed does not provide a workable
solution in that case.
2. Is the feed state mechanism a way of paging through the current
contents of a collection or a snapshot-in-time view of a feed? That
is...
is it
A) Collection has a bunch of entries. Each feed
representation has 15 entries and the prev link
acts like a paging mechanism similar to what we see
currently use in search results. Deleting
the first ten entries out of the collection would cause
all of the entries in the feed to "shift backwards"
in the feeds
B) Each prev link is representative of how the feed looked
at a given point in time. E.g. the feed as it would
have appeared at a given hour of a given day
If it's A, then Bob's RFC3229+feed solution seems much more
efficient. (see #1)
If it's B, then I'm wondering why you don't just use an ETag
based approach, e.g.
<fs:Stateful>1</fs:Stateful>
<fs:prev>{ETag}</fs:prev>
This would allow clients to only ever have to deal with a single
URI for a feed and use conditional-gets with ETag to differentiate
which snapshot of the feed they want to get and would likely make it
easier to remediate potential recursive reference attacks, (e.g.
feed A references feed B which references feed C which is a blind
redirect to Feed A).
This proposal doesn't handle deletion or other aspects of identity in
feeds; I tried to introduce language like that earlier in Atom
itself, but we failed to gain consensus around it.
How does an ETag help you locate a previous feed to reconstruct
state? Even if it could, I'm not sure intermingling HTTP protocol
details with application semantics; although there's nothing to
prevent this theoretically, in many implementations, it might be
problematic to predict what the ETag is.
It's not so much using ETag to reconstruct state as much as it is to
view access previous views of the feed. Btw, I threw this out for
discussions sake and not because I think it's the "right" solution. I'm
not particularly in love with it myself.
3. Microsoft's RSS Lists spec uses <cf:treatAs /> to attach
behavioral semantics to a feed. This proposal uses <fs:Stateful />
to attach behavioral semantics. It would be nice if we could come
up with a relatively simple and standardizable way of attaching
behavioral semantics. For example, a standardized <treatAs /> element:
<atomex:treatAs>stateful</atomex:treatAs>
The value of the treatAs element would be a list of tokens with
defined semantics. Each token SHOULD be registered with IANA.
Unknown tokens would be ignored. Incompatible tokens would be
ignored with first-in-the-list takes precedence semantics. For
example:
<atomex:treatAs>stateful list</atomex:treatAs>
Indicates that the feed should be treated as a list whose past
states can be queried using the kind of mechanism you've defined.
That seems like an awfully heavyweight solution. What does defining
the container and an IANA registry add?
The value is that I would really like to see a common and consistent way
of attaching behavioral semantics to the feed rather than each
individual vendor / spec defining their own app and impl specific
methods. It could be done without IANA support, of course, but it's
just annoying to see relatively similar tasks done in completely
different ways.
--
Mark Nottingham http://www.mnot.net/
