Symmetric: means that the model for a subscriber being updated by a publisher is the same as the model for a publisher updating a subscriber.
On Mon, Jan 11, 2010 at 8:31 PM, Ivan Žužak <[email protected]> wrote: > Not sure what "symmetric" implies exactly, but if it means that > publisher, subscriber and hub define roles, not components, and that a > component may implement multiple roles -- then that's what I have in > mind also. A component may thus, for example, both subscribe and be > subscribed to. So, yeah, this sounds like an option to be specified. > > Cheers, > Ivan > > On Mon, Jan 11, 2010 at 20:45, Alexis Richardson > <[email protected]> wrote: >> 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 >>>>>> >>>>> >>>> >>> >> >
