Yes, it may do. And yes in my mind it means that too :-) Thanks for posting the dialogue about fat pings.
On Mon, Jan 11, 2010 at 8:41 PM, Jeff Lindsay <[email protected]> wrote: > Yes. Although that symmetry might be functionally or high level in practice > than meaning the exact same interface/protocol. In my mind, it means both > use HTTP POST. ;) > > On Mon, Jan 11, 2010 at 12:36 PM, Alexis Richardson > <[email protected]> wrote: >> >> 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 >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > > > > > -- > 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 >
