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 >
