On Tue, Oct 6, 2009 at 9:20 AM, Niko Sams <[email protected]> wrote: > If PSHB doesn't support deletion, then I must > fetch the original feed on every notification - > and ignore the supplied atom feed completely. Why would you "fetch the original feed on every notification"? What information would you get by doing that? Atom provides no means to mark an item as deleted. Thus, reading the feed won't tell you what is "deleted."
I'm assuming that you realize that the mere removal of an item from a feed is *not* the same as deletion. In this context, a "deletion" is really more like a "retraction." The contents of a feed document are only a sliding window on the virtual "feed" of all entries published to the feed over time. The presence or absence of an entry in any particular feed document does not carry information. The "life" of an entry is independent of its presence within any particular feed document. What do you learn by fetching the original feed? (Note: The atom format spec would say: "Nothing!") bob wyman On Tue, Oct 6, 2009 at 9:20 AM, Niko Sams <[email protected]> wrote: > > Hi, > > > Deletion in this kind of system is exceptionally difficult. This is why > we > > left any form of deletion out of the Atom spec itself. Please don't go > down > > this path without a great deal of careful consideration... PSHB is > getting > > more and more complicated all the time. Do you really want to deal with > the > > mess that will be created if folk think you're trying to handle > arbitrarily > > complex distributed synchronization issues including deletions? > If PSHB doesn't support deletion, then I must fetch the original feed > on every > notification - and ignore the supplied atom feed completely. > Even if it is difficult - it is very important. > > Niko >
