Subject: Re: Tools that make use of previous/next/first/last links?

From: [email-masked] (Peter Robinson)
Date: Mon, 1 May 2006 11:16:41 +0100

Mark Nottingham <[email-masked]> 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&amp;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&amp;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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 May 2006 20:23:47 -0700

Peter,

Can you expand upon "being more precise about exactly what is needed"?

--
Mark Nottingham     http://www.mnot.net/

---

From: [email-masked] (Peter Robinson)
Date: Wed, 3 May 2006 23:26:44 +0100

> Can you expand upon "being more precise about exactly what is needed"?

I don't have time to go into very much detail right now, but basically
it's about what people are calling 'stable urls' in another part of this
thread.

The draft calls feeds where it's sensible to maintain a history
'incremental feeds', but defines an incremental feed as a 'subscription
document' plus a series of 'archive documents'.  An archive document is
defined as a feed (url) whose entry set doesn't change.

It was necessary for you to require 'archive documents' with fixed
element sets because your history reconstruction algorithm's state is
stored as feed urls.  If you rework  the algorithm so its state is
stored in terms of <atom:id>s or <guid>s then you no longer require
archive documents to have fixed entry sets (and they probably shouldn't
be called archive documents in that case).

I need to write down a concrete algorithm that remembers <atom:id>s
instead of feed urls, but I believe that is perfectly possible (without
any particular extra burden on the client) if you have these two
requirements (which need more formal wording):

- new entries can only be inserted at the start of the 'logical feed'
- old entries can only be deleted at the end of the 'logical feed'
(you can weaken these to make no requirement of the order within a
single feed document's xml as long as the 'real' order is preserved on
the server)

The simplest way to satisfy those two requirements is to have a
conventional feed where the entries are ordered by publication date and
none are ever removed.

For a feed that satisfies those requirements whose pages are all
'sliding windows' it's not possible to miss any entries if you traverse
the next/prev links in the right direction.

Regards,

Peter