That's interesting that you felt that way and yet so many Atom users actually created Atom documents that aggregators used in a very similar way to RSS. You would have thought that a different paradigm would have emerged similar to XMPP. Maybe this time around.
On Wed, Oct 7, 2009 at 12:14 PM, Bob Wyman <[email protected]> wrote: > 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 > > > > >
