Sorry. I was confused about what was being proposed... Disregard earlier comments. I'll have more relevant comments shortly in a new message.
bob wyman On Sun, Nov 20, 2011 at 4:49 PM, Julien Genestoux < [email protected]> wrote: > 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 >> > >> > >
