On Thu, Oct 15, 2009 at 8: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? > There's an obvious solution to that: Even more hubs! If you have an app that expects to subscribe to many feeds from diverse hubs, you can run your own hub, subscribe to feeds with that hub, and let it deal with everything. > > 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 >>>> >>> >>> >> > -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
