Hey Mark,
A few comments after my first read through on this:
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.
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).
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.
- James
Mark Nottingham wrote:
Hi Danny,
Thanks for the comments.
On 29/06/2005, at 1:57 AM, Danny Ayers wrote:
Trivial: might 1/0 be confusing compared to something clearly binary:
true/false or yes/no, and difficult to extend: true/false/unknown
ack
What is the Stateful nature of a feed *without* a Stateful element,
the default if you will? (Could be per-case or 'indeterminate', but I
think some comment on this would be helpful).
Yes, that's the intent; if you don't have a flag, there isn't any
information about what it is (or isn't), and you act as you would today.
If you're talking about feed reconstruction, might it not make sense
to have something like an "all" (which could appear as a minimal list
of dated URIs of entries) to avoid countless GET/interpret cycles?
I put that forth in the original Pace <http://www.intertwingly.net/
wiki/pie/PaceFeedState> (see history), and it got very negative
reviews, because it requires a lot of work to maintain, and can be a
bandwidth hog. I'm of two minds about it.
--
Mark Nottingham http://www.mnot.net/
