Re: Feedback on Tombstones -04

["Mark Stahl" <mstahl@xxxxxxxxxx>]

MarkN,

The idea of interleving entries and deleted-entries in edited order sounds like a good pattern.  It's particularly useful  for clients attempting to retrieve the most recent changes.  Combining this idea with the idea of a tombstone "lifetime", then, one could construct a feed that looks something like this: 

<feed>
   <entry> ... updated at T ... </entry>
   <at:deleted-entry> ... deleted at T-1... </at:deleted-entry>
   <at:deleted-entry> ... deleted at T-2... </at:deleted-entry>
   <entry> ... updated at T-3 ... </entry>
   <at:deleted-since>T-4</at:deleted-since>
   <entry> ... updated at T-5 ... </entry>
   <entry> ... updated at T-6 ... </entry>
   ... 
</feed>

I would not recommend this order be required.  But it would be very useful for clients attempting to learn of changes to the feed since the last time they accessed it. 

-- m

On Wed, May 7, 2008 at 8:45 PM, Mark Nottingham <mnot@xxxxxxxx> wrote:

In a paged feed, I just put the tombstones on the page that's appropriate; e.g., if the entries are sorted by date (and most are), the tombstone goes on the relevant page (i.e., using the time of deletion).

On 08/05/2008, at 2:19 AM, Mark Stahl wrote:

One issue that we've encountered with tombtones is that most services don't keep them forever.     (Otherwise, the list of tombstones only ever grows.)

This leads to problems with clients that periodically poll for changes - they don't know if the set of tombstones is complete since the last time they polled.

I'd suggest adding an element at:deleted-since, so the server can let the client know the tomebstone window in effect.  Building on the proposal for at;deleted-entries, I'd suggest something like this:

<at:deleted-entries>
 <at:deleted-since>2003-12-13T18:30:02.25Z</at:deleted-since>
 <at:deleted-entry .../>
 <at:deleted-entry .../>
 <at:deleted-entry .../>
</at:deleted-entries>

Another useful piece of information to the client trying to sync is a hint as to the typical tomebstone lifetime.  But I'm not sure if it belongs in this spec. (Perhaps it's more appropriate in a service document?)

-- mark


On Tue, Apr 22, 2008 at 5:15 PM, Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx> wrote:

On 23/4/08 3:46 AM, "Brian Smith" <brian@xxxxxxxxxxxxxx> wrote:

> Why not have at:deleted-entry contain app:edited and/or atom:updated
> instead of @when? Then say that timestamps should be compared using the
> same date construct (compare only app:edited to app:edited, and
> atom:updated to atom:updated). AtomPub collections would use app:edited
> and most other collections would use atom:updated, just like they do
> with atom:entry already today.

+1 : elegant, simple

> This would allow a feed to indicate that it supports this feature, even
> when no entries have been deleted:
>
>   <at:deleted-entries/>
>
> Knowing that the collection provides these tombstones would all clients
> to skip crawling the collection to look for deleted entries.

+1 also

e.




--
Test driving http://five.sentenc.es/

--

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

-- 
Test driving http://five.sentenc.es/