Ivan Thanks! I am cc'ing Mike.
I reckon that our contention is that being BOTH a (publishing) hub AND a subscriber requires treating the protocol as symmetric. This may require specifying, ideally as an option for PSHB. alexis On Mon, Jan 11, 2010 at 7:42 PM, Ivan Žužak <[email protected]> wrote: > Thanks Alexis! I responded to Mike on the blog. In short -- chaining > of hubs would not require changing the protocol, just the types of > components which implement parts of the protocol. Instead of having > just pure publishers, subscribers and hubs, there would be components > that implement multiple roles (e.g. a hub that supports chaining would > be both a hub and a subscriber). As Jeff said - this can all be broken > down to webhooks. > > Regular PSHB subscription would still work as before. > Publishing/filtering would just be an extension which a hub MAY > support. Of course, this requires some kind of fallback negotiation > for cases when a component doesn't support an extension requested by > another component. > > Ivan > > On Mon, Jan 11, 2010 at 19:21, Alexis Richardson > <[email protected]> wrote: >> Ivan, all, >> >> Mike Bridgen has elaborated on this in the comments to the post. >> >> I am copying his comments here: >> >> --- >> >> pubsubhubbub (0.1, anyway) doesn’t chain together in the way you’ve >> illustrated, because it’s not symmetrical — hubs don’t get subscribed >> to other hubs (or indeed, subscribe themselves). While you wouldn’t >> have to change the protocol, you would have to change the idea of what >> a hub is. But I guess you are setting out to do that anyway. >> >> For processing I can subscribe the remote processing service to the >> hub, and subscribe myself to the remote processor. Taking into account >> the verification, it would probably go >> 1. Me -> Remote: Please give me a token for this hub to post to you >> 2. Me -> Remote: Please subscribe me to you >> 3. Me -> Hub: Please subscribe Remote using this token >> This requires me and the remote processing service to understand some >> generalised bits of PSHB, but nothing extra of the hub (I don’t >> think). >> >> --- >> >> Cheers, >> >> alexis >> >> >> >> On Mon, Jan 11, 2010 at 5:21 PM, Alexis Richardson >> <[email protected]> wrote: >>> Ivan >>> >>> Possibly related to what Jeff says: how do you think hub-hub chaining works? >>> >>> Separately does PSHB subscription still work in your model? >>> >>> Great article btw. >>> >>> alexis >>> >>> >>> On Mon, Jan 11, 2010 at 5:14 PM, Jeff Lindsay <[email protected]> wrote: >>>> You should look into the greater webhooks ecosystem (slowly being called >>>> the >>>> Evented Web). It's all about the things your talking about here. >>>> http://webhooks.org >>>> Of particular interest might be Scriptlets (currently undergoing a major >>>> upgrade) and DrEval. >>>> -jeff >>>> >>>> On Mon, Jan 11, 2010 at 5:20 AM, Ivan Žužak <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Just wanted to point to my new blog post - http://bit.ly/5PMXGq. In >>>>> short, it's about extending PSHB to support not only real-time >>>>> delivery of feeds but also their filtering and processing via 3rd >>>>> party services. As I write in the post, I've discussed some of these >>>>> ideas a few months back with Julien (over email) and Brett (over >>>>> FriendFeed) but never got around to starting a broader discussion with >>>>> concrete ideas. >>>>> >>>>> Feedback is welcome and if it's mostly positive I think that would be >>>>> a good signal to start defining an extension to the protocol which >>>>> supports this. >>>>> >>>>> Thanks, >>>>> Ivan >>>> >>>> >>>> >>>> -- >>>> Jeff Lindsay >>>> http://webhooks.org -- Make the web more programmable >>>> http://shdh.org -- A party for hackers and thinkers >>>> http://tigdb.com -- Discover indie games >>>> http://progrium.com -- More interesting things >>>> >>> >> >
