Then we're coming back to the debate we had a few weeks ago where subscrubers should either:- subscribe to the right hub (the one mentioned in the feed) - subscribe to their favorite hub, as long as this one susbcribe to the right hub.
-- Julien Genestoux, http://twitter.com/julien51 http://superfeedr.com +1 (415) 254 7340 +33 (0)9 70 44 76 29 Sent from Newark, CA, United States On Thu, Oct 15, 2009 at 12:30 PM, Bob Wyman <[email protected]> wrote: > > The subscribe just cares about getting a > > callback on new content. Who cares where > > it comes from? > Given N subscriptions, it seems more difficult to manage relationships with > N hubs than it is to manage a relationship with one hub. (If nothing else, > it takes more memory...) Also, being able to minimize the number of hubs > that a subscriber works with means that there are likely to be benefits from > HTTP keep-alive persistent connections and potentially via hub-based > aggregation of notifications. etc. What am I missing? > > bob wyman > > > On Thu, Oct 15, 2009 at 3:17 PM, Brad Fitzpatrick <[email protected]> wrote: > >> I don't see the problem with each publisher being a hub. >> Why does there need to be a hub of hubs? >> >> The subscribe just cares about getting a callback on new content. Who >> cares where it comes from? >> >> On Thu, Oct 15, 2009 at 12:14 PM, Bob Wyman <[email protected]> wrote: >> >>> The easy provision of white-label hubs will, of course, lead to the >>> creation of many more hubs than might otherwise have existed... This is >>> probably a good thing. But, there are issues... >>> >>> It is interesting, I think, to contemplate what the result would be if >>> *every* blog and feed ended up having its own hub. I don't suggest this >>> mental experiment because I think that we should seek to achieve such a >>> state of affairs, but rather because exploring the "extremes" is always a >>> good way to find issues with specification... >>> >>> Clearly, if every feed was its own hub, we would see a need to build >>> "hubs of hubs" in order to simplify the tasks of managing subscriptions, >>> controlling message sending patterns, achieving efficiencies through >>> minimization of connections, aggregation of notifications, etc. But, it >>> seems that doing that given the PSHB spec as it stands would not be easy. >>> The problem is that hub discovery depends on data which is published in the >>> feed itself and there exists only one class of hubs in the current spec. You >>> can't, for example, distinguish between a hub and a "hub of hubs"... Also, >>> even if a "single feed hub" were aggregated by one or more hub of hubs, it >>> is questionable whether the feed author would know about any of the hubs of >>> hubs and thus be able to mention them in the feed. >>> >>> I think there are issues here that need to be resolved... >>> >>> bob wyman >>> >>> >>> On Thu, Oct 15, 2009 at 12:10 PM, Julien Genestoux < >>> [email protected]> wrote: >>> >>>> Hi, >>>> We just introduced what we call "white-label hubs" at superfeedr : >>>> http://blog.superfeedr.com/API/publishers/pubsubhubbub/white-label-hubs/ >>>> >>>> In a nutshell : your service can give us access to his stream/firehose >>>> and we'll turn that into a PubSubHubbub hub in snap! >>>> >>>> Examples : >>>> - A wordpress.com PubSubHubbub : http://wordpress.superfeedr.com/ >>>> - An Identi.ca PubSubHubbub : http://identica.superfeedr.com/ >>>> >>>> Let me know what you guys think! >>>> >>>> Ju >>>> >>>> PS: if you're at RWW's realtime event, come and chat : I am @julien51, >>>> the tall french guy wearing a yellow shirt, who looks a little bit tired >>>> (guess why!) >>>> >>>> -- >>>> Julien Genestoux, >>>> >>>> http://twitter.com/julien51 >>>> http://superfeedr.com >>>> >>>> +1 (415) 254 7340 >>>> +33 (0)9 70 44 76 29 >>>> >>> >>> >> >
