On Mon, Jan 11, 2010 at 8:55 PM, Julien Genestoux <[email protected]> wrote: > I agree with Jeff that symetry doesn't necessarily mean that the publication > (hub -> subscriber) and the ping (publisher -> hub) should be considered > identical.
At the risk of sounding pernickety, in what other way can delivery of data and consumption of data be symmetric? Thin ping is a great way to notify people that something may have changed, and provide context, in a long running setting. This is the insight of PSHB 0.1/0.2. > As a matter of fact, the hub shouldn't trust the ping so it has > to poll the feed anyway. Should not - or should not have to? I think that 'should not' is an overly restrictive assumption in the general case which specifically includes hub to hub. > Yet, there is nothing that prevents a hub from > considering a publication like a ping (that's what superfeedr does > actually). Agreed. a > > > -- > Julien Genestoux, > > http://twitter.com/julien51 > http://superfeedr.com > > +1 (415) 830 6574 > +33 (0)9 70 44 76 29 > > > On Mon, Jan 11, 2010 at 9: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 > >
