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. I don't see how either way is harder or easier. It seems like it'd be identical. > (If nothing else, it takes more memory...) Not sure I agree with that, either. What schema you thinking of for a subscriber's state? 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? > Yes, these are benefits, but not huge. Anybody running their own tiny hub (in a hypothetical everybody-is-also-a-hub world) is probably small, and probably low volume enough that persistent connections & aggregation onto them doesn't matter. So in practice I imagine there will be a bunch of small hubs and a handful of large hubs that are efficient. I'm not worried about the efficiency of the small hubs. > > 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 >>>> >>> >>> >> >
