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 <[EMAIL PROTECTED]> 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 < > > [EMAIL PROTECTED]> wrote: > > > > On 23/4/08 3:46 AM, "Brian Smith" <[EMAIL PROTECTED]> 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/
