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 >
