Well, the problem is that there is a lot of very significant changes to be pushed to the core of the protocol that will make some existing implementation obsolete. We can also chose to not change anything, but that's probably worse, as the current protocol is not wide enough to cover a lot os use cases that needs to be covered : arbitrary content and private feeds just to name a few. If we want to work on this topic, I'm on favor on cleaning things up first.
In my mind, hubs should still be compatible with draft 0.3, but the protocols needs to evolve to 0.4. This means that if a subscriber provides a verify_token, the hub will deal with it just fine, but this should not be part of the following versions of the protocol. What does everyone think? Julien On Mon, Nov 28, 2011 at 4:44 PM, Tamer Yousef <[email protected]>wrote: > Trying to catch up here... > Removing the verify_token is not significant as it's an optional > parameter in the current specs anyway, I'm leaning toward keeping it > because if you remove it, lots of developers will need to > review their existing code to make sure no bugs are introduced because of > this change. > > On my side here, I use query strings in the call back urls to identify not > only the hub, but also some unique ids for my own records. > > > -Tamer > > On Mon, Nov 28, 2011 at 3:29 AM, Julien Genestoux < > [email protected]> wrote: > >> Yup. I just did that. >> >> >> On Mon, Nov 28, 2011 at 3:50 AM, Monica Keller >> <[email protected]>wrote: >> >>> Looks good to me. >>> Shall we (git) rename >>> "pubsubhubbub-core-0.3.xml<https://github.com/pubsubhubbub/PubSubHubbub/blob/master/pubsubhubbub-core-0.3.xml>" >>> to >>> "pubsubhubbub-core.xml<https://github.com/pubsubhubbub/PubSubHubbub/blob/master/pubsubhubbub-core-0.3.xml>" >>> and then add a 0.3 tag ? >>> >>> I rather use tags for versioning and keep editing the same file. Once we >>> are happy with a 0.4 we can tag that >>> >> >> >
