Re: Feedback on Tombstones -04

["Mark Stahl" <mstahl@xxxxxxxxxx>]

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/