Thanks ! Feed and Stream are both good terms. Slight preference for Feed based on the terminology already in the 0.3 spec.
Do we think that people will ever want "whole" resource notification for a feed ? I can't think of a use case so I am leaving that part out for now and just focusing on describing topics as feeds and non feeds Also I would rather not require that feeds have the hub declaration inside the content always given that for example existing parsers that fetch lists/array would now need a head item in the body to declare the hub. On Tue, Jun 15, 2010 at 1:39 PM, Martin Atkins <[email protected]>wrote: > On 06/15/2010 01:28 PM, Kevin Marks wrote: > >> Is 'Feed' a usable term? Thats widely used or Atom + RSS, but I've seen >> it used for JSON too, eg http://jsonduit.com/ >> >> > In my JSON PubSubHubbub draft I used the term "stream resource" to describe > the more general idea of a resource that consists of a bunch of items which > each have distinct lifetimes, in an attempt to express a superset containing > the idea of a feed of the kind you'd expect to load into a "feed reader" for > human consumption as well as more machine-oriented data. > > However, I'm by no means wedded to the idea. > > Perhaps it would be better to make a distinction on type of subscription > rather than type of resource. > > All resources support a "whole-resource subscription" which re-delivers the > entire resource each time it changes. > > Some resources support "stream-based subscription" which delivers new items > and changes to existing items in a particular media type. > > The Link header defines a resource's hun for whole-resource subscription, > but a hub for a stream-based subscription is determined via a mechanism > specific to the stream media type. > > > >
