Farukh, You're perfectly right, the spec currently applies to feed (RSS/Atom) and hence allows for diff-ing on en entry by entry basis. Basically, the hub is expected to push only the "new" entries of a feed. The definition of "new" is currently based on <id> and <guid> elements, as well as updated times (for updates).
Since it is one of the current goals to make sure the spec applies to any kind of arbitrary content, we will have to change this in the core spec, however, room will be left for formats that support diffing pretty well (including feeds). I hope this helps, Julien On Tue, Nov 15, 2011 at 10:32 AM, Farrukh Najmi <[email protected]>wrote: > > > Hi Guys, > > I am relatively new to pubsubhubbub and working on the > certeorem<https://rometools.jira.com/wiki/display/INCUBATOR/certiorem>implementation > of the spec. > > The current spec for Content > Distribution<http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#contentdistribution>(notification > from hub to subscriber) has the following statement: > > "Essentially, in the single feed case the subscriber will receive a feed > document that looks like the original but with old content removed" > > This seems to imply that the spec has some mechanism for supporting > content distribution using a feed that only has entries that have been > change since last Content Distribution. > This seems to be extremely important for feeds with large number of > entries that is changing frequently (which is my situation). > > Can any one share some details on what the spec behavior is related to > delta content distribution, what holes if any are known to exist in spec in > this area and what implementation experience we have with this. > > Thanks for your help. >
