On Wed, Oct 7, 2009 at 10:59 AM, Matthew Terenzio <[email protected]>wrote: > But to say there is no use case for knowing > the current state of the feed (if that is what > you were saying) seems to be over-reaching > even if it wouldn't help in this case. The "current state of the feed" is, by definition in Atom, irrelevant. Atom is about entries, not feed documents. Feed documents are simply collections of entries that have, at some time, been associated with the "feed." (Note: A "feed document" is a concrete object. A "Feed" is a conceptual thing -- a potentially un-ending stream of entries.) While in common usage, the entries in a feed document will be the most recent subset of entries associated with the feed and those entries will normally be inserted into the feed document in the order that they were created or updated, these artifacts of "normal" usage are defined in Atom as having no semantic content. I realize that this probably seems like a fairly subtle point, however, it was the need to address this kind of subtlety that was a primary motivator for the definition of Atom in the first place. Issues like this are not, for instance, dealt with in the definition of RSS... (Grumble...)
It is perhaps important to remember that when we were defining Atom, we had in mind (among many other things) systems that worked in precisely the same manner that PSHB does. PSHB is, after all, simply an HTTP REST implementation of a subset of the capabilities that we were then delivering based on XMPP/PubSub, or even before that with BEEP/APEX PubSub... As a result of our experience with this pattern of application, we knew that if the "current state of the feed" had meaning, then it would introduce all sorts of undesirable and usually unnecessary complexity into these systems. Thus, we defined the problem out of existence by saying that it is entries that matter, not feeds. The presence or absence of an entry in a feed document at any specific time is irrelevant and so is the order of entries within a feed document or the co-occurence of entries in a feed document. This massively reduces the complexity of PSHB like systems and, in fact, allows them to gain greater efficiencies and utility since they can focus just on distributing entries without having to worry about distributing all kinds of information about feed state. Now, while it is really useful to establish the base principles that Atom does, it is recognized that there are often *application* requirements for an ability to "retract" or "remove from circulation" some entry or the information contained in an entry. Often, this can be accomplished by simply inserting into the feed an updated version of the entry. (Perhaps the title, body, and summary now all read: "deleted"...) For applications that need some stronger semantic for "deletion" or "retraction," it might make sense to define an application specific extension that explicitly flags things as retracted. For instance, you might be publishing "Offers to sell" or "Offers to buy" in Atom. At some point you want to be able to explicitly retract your offer -- perhaps because you sold all available units. You might also want to be able to "expire" your offers after some specific amount of time -- whether or not you actually bought or sold anything. While retractions, cancellations, expirations, etc. are all wonderfully useful ideas, it turns out that it is very difficult to define a single model for these things that will apply to all cases. Thus, Atom doesn't address these issues and leaves it as a problem for applications and extensions layered on top of Atom. I suggest that PSHB should take the same approach. PSHB should focus on providing the means by which entries flow between publishers and subscribers -- it should leave interpretation of the entries up to other services and/or applications. bob wyman On Wed, Oct 7, 2009 at 10:59 AM, Matthew Terenzio <[email protected]>wrote: > If an item in the feed is removed and you fetch it within the given window, > it won't be there. > > If I store a cache of the feed on my server and update it when there is a > change, the entry will no longer be on my server either. > > Surely there must be some aggregators that have worked like this, no? > > You are very much right that it is not the same as deletion and the life of > an entry would be independent of the feed even if deletion were available in > the spec because not everyone might support it or as you suggested, the > entry might have moved downstream. > > But to say there is no use case for knowing the current state of the feed > (if that is what you were saying) seems to be over-reaching even if it > wouldn't help in this case. > > > > On Tue, Oct 6, 2009 at 12:16 PM, Bob Wyman <[email protected]> wrote: > > 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 > > > >
