On 10/23/2009 4:44 PM, Pádraic Brady wrote:
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.

    Given the very drastic change Brett suggested re: atom:ids, which would make everything about 0.2< incompatible with 0.3>, I think it warrants discussion now.  People are implementing these specs right now.  While it's known that they're going to move forward, most changes are relatively trivial in the long run.  Between two revisions of the spec, it might not even be necessary to change the protocol version because it's backwards compatible, but some changes aren't going to be compatible at all, and it will leave clients wondering why the hell their subscription requests stopped working all of a sudden with no clear reason why.  At least if there's a documented response, they'll understand what's going on.


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.

    (With the exception of outbound aggregation which isn't a hub requirement, I claim complete 0.2 support.  :p)

--

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

Reply via email to