On Wed, Oct 7, 2009 at 12:40 PM, Matthew Terenzio <[email protected]>wrote: > yet so many Atom users actually created > Atom documents that aggregators used > in a very similar way to RSS. A great many people put a great deal of effort into making Atom better than the previous formats. This involved, as I've indicated, thinking through a great many use cases that were not well handled by the many flavors of RSS. However, the community has never really been able to benefit from the work due to the heavy political pressure to maintain backwards compatibility with the legacy RSS format. Thus, we saw many feed producers who generated both RSS and Atom feeds and, because it is easier to do, they ended up implementing the "lowest common denominator" for both feed formats. We also see that virtually every tool that consumes either RSS or Atom also consumes the other. Thus, since virtually everyone that produces feeds produces Atom and virtually everyone that reads feeds reads Atom, there is simply no technical reason for anyone to continue to support the legacy RSS format. Continued support for RSS does nothing but prevent innovation and progress in this space. This is a high price to pay in order to support the ego of a single individual...
bob wyman On Wed, Oct 7, 2009 at 12:40 PM, Matthew Terenzio <[email protected]>wrote: > 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 > > > > > >
