Bob, I think Alexis comment should have cleared up any doubt... but just in case, here is how I view things.
The "consumers" (I believe you are describing the subscriber in the pubsubhubbub dialect), are actually never aware of how the hub got the content it pushes to them. As you pointed, it would be no different from how it is done right now. However it is not what the spec says. The spec currently specifies how the publisher should ping the hub... and well, at least for Superfeedr's hub, it is rarely how things actually happen. I believe it is not how things happen for other hubs hosted directly by the publishers (wordpress...). As for your last paragraph, I think there is a misconception. Right now, a hub never advertises the feeds that are available thru it... it's the publisher (thru the feeds) that advertises the hub. Which means that in the context of delegation, the feed can just simply point to several hubs (and many feeds do already). Finally, in the context of chaining, once again the subscriber don't really need to know how the hub "learnt" about the update. It is actually a big chunk of Superfeedr's business : some susbcriber subscribe to Superfeedr's hub for any feed, including the ones that have a hub in them. When that happens, superfeedr subscribes to the actual hub (as pointed to by the publisher), and then pushes the updates forward to the subscriber. I hope this helps, julien On Sun, Nov 20, 2011 at 10:34 PM, Alexis Richardson <[email protected]>wrote: > Publishers could be seen as posting content to a local topic which > consumers express interest in by talking to the publisher. Then, a > hub is just a consumer that republishes using the same topic name. > > > On Sun, Nov 20, 2011 at 9:28 PM, Bob Wyman <[email protected]> wrote: > > If the publisher->hub part of the spec is removed, how will consumers of > > feeds express their interest in receiving updates? How would that > process be > > different from what is currently specified for subscribing to hubs? Would > > there protocol for subscribing to a single feed publisher be distinctly > > different from subscribing to a publisher that handles multiple feeds? > > If, as Monica suggests, it is clarified that a publisher can serve as > their > > own hub, isn't that sufficient to accomplish the goals you've specified? > > It is likely that some consumers will prefer to receive updates > indirectly > > via a small set of hubs even if publishers are able to send those updates > > directly. In such cases, it would be desirable for a publisher to specify > > not only that it serves as its own hub but also delegate to one or more > > multi-publisher hubs. (Note: A hub that serves many publishers should be > > able to achieve a variety of efficiencies that would not be achievable if > > all feeds were served by their publishers. e.g. various aggregation > options > > as well as reuse of existing connections.) > > bob wyman > > > > On Sun, Nov 20, 2011 at 10:59 AM, Julien Genestoux > > <[email protected]> wrote: > >> > >> All, > >> I believe that the Publisher -> Hub part of the protocol should be left > >> out of the "core" spec. > >> The motivation behind it is that many hubs out there (Wordpress, > >> Superfeedr's... etc) have different ways of handling this without > affacting > >> much of how the general "idea" of the protocol works. > >> I believe the Section 7.1 should be set as optional, as well as section > >> 7.2. > >> Something like this would work well, according to me : > >> Once a publisher designates a hub he wants to use, he then SHOULD use > any > >> of the supported method by this hub to notify new content. 7.1 and 7.2 > >> should certainly be put as an annex/example of how this can be done. > >> What do you think? > >> Julien > > >
