Mark Nottingham <[EMAIL PROTECTED]> wrote: > One thing I did notice -- you're using URLs like this for your archives: > http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? > page=2&count=10 > > Are they really permanent? If they're relative to the current state > of the feed (i.e., the above URI means "give me the ten latest > entries"), you can get into some inconsistent states; e.g., if > somebody adds/deletes an entry between when the client fetches the > different archives. Also, if a client doesn't visit for a long time, > it will see > http://journals.aol.com/panzerjohn/abstractioneer/atom.xml? > page=2&count=10 > and assume it already has all of the entries in it, because it's > fetched that URI before.
This is the biggest issue I have with the history spec as written. I have urls like that, which aren't 'archive documents' as defined. That means I can't implement the history spec even though I have conventional chronologically ordered feeds with link rel="prev/next" elements where old entries are available. I believe that by being more precise about exactly what is needed by the client to implement feed history usefully you can significantly relax the requirements. I believe the algorithm can be written so that clients can use history with a feed like mine. Regards, Peter
