On Sat, 20 Nov 2004 19:49:19 -0800, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> http://www.intertwingly.net/wiki/pie/PaceFeedState [I typed before seeing Bill's response, I think's there's a bit of overlap] I'm not sure about some details (below) of what you've got at the moment but do reckon it would be useful to have some description of state management. If anything I'd like to see it expanded beyond desktop readers to describe caching apps, where the state will perhaps be even more significant. (i.e. put on the REST spectacles). There's also the well-known hassle of moving a blog from one server to another. In "Feed State Model" the assumption is being made that the order of the entries in the feed representation is significant (most recent at the top). I could be wrong, but I don't think that's in the spec. "Reconstructing Feed State", seems to me to be expecting rather a lot of the client, to remember every change and every feed head. I wouldn't have though a warning should be needed in its absence. Under what circumstances would the client actually want to reconstruct feed state? My guess is that would fall outside 80/20 applications. If anything like that does need to be preserved, might it not be the receipt order of the entries? (rel="previous" on entries perhaps) I think a note to clarify sort order etc would be helpful. Is 'wholefeed' feasible/desirable? I wouldn't have thought so outside of 'control' circumstances. How do you tell the difference between wholefeed (containing all revisions of entries) and wholefeed (containing only the latest)? Delete - yep, separate. As suggested in a recent thread, it would make most sense to have delete mean "removed from view" rather than "removed from existence". In which case it's only impact on the state would be the change of an attribute rather than any structural revision. fyi, Henry's done quite a bit of experimentation with state and entry versioning modelling in OWL (in Bloged), though I haven't any links at hand. Cheers, Danny. -- http://dannyayers.com
