Is this needed so early though? I expect new versions to roll out pretty frequently on the order of months until 1.0 is reached, and from an implementation perspective this could quickly become a nightmare of allowing a method which might validate supporting one version and not updating to the next. When we start looking at a version 1.0, this would have its uses, but while we're still moving between 0.1 to 0.2 to a future 0.3 it's far more important to put the emphasis on moving with the times and not allowing Subscribers or anyone else the luxury of implementing 0.1/2 and deciding they're done - forcing other implementations to follow suit with a mish mash of code designed to change every little protocol nuance that differs. I'm already this in my own code, and if we strike 0.3 when 0.2 is yet to be fully implemented, it will just get progressively worse. At 1.0 - I'd agree it makes sense but not for the current minor revisions.
Here's an interesting question - how many Hubs currently claim complete 0.2 support? ;) We're stuck with the mish mash until the specification hits some final milestone or implementations and specs somehow synchronise closer in time. Getting some more open source libraries out there would help this along, as would getting more programmers on team. Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Jay Rossiter <[email protected]> To: "[email protected]" <[email protected]> Sent: Sat, October 24, 2009 12:12:52 AM Subject: [pubsubhubbub] Protocol versioning Something that's not addressed anywhere in the spec currently is protocol versioning. I think it becomes fairly evident that as the protocol changes (in some suggestions, quite drastically, such as using atom:id instead of atom:link[rel=self] for feed identifiers), things could become very out of sync between what subscribers and hubs support. In my opinion, there's a real need/benefit to adding an "X-PuSH-Version:" (revise naming as you will) header for all outgoing connections. The receiving host should respond appropriately (415 Unsupported Media Type ?) if a version is unsupported. This would alleviate confusion once the protocol starts to diverge from its current state, and different specs become incompatible with each other. -- Jay Rossiter | Software Engineer/System Administrator Pioneering RSS Advertising Solutions [email protected] | Phone: 503.896.6187 | Fax: 503.235.2216 Website: www.pheedo.com | RSS: www.pheedo.info/index.xml
