Rafael Schloming wrote:
so the only
reason I can see for us to keep basic is if we want to choose right now
to start being pedantic about spec compliance.
[...]
It would certainly be possible to support both versions, however in my
view this would be a waste of time. The only circumstance under which
this would help us is in the *extremely* unlikely event that the working
group decides to entirely remove the WIP portions for 0-10 and regress
the protocol to 0-8, and even then we might as well wait until that
point to do the work since it wouldn't be significantly more difficult
then than it would be right now.
[...]
I think the trunk should reflect the direction the spec is moving, which
is in this case towards the 0-9 WIP, as well as towards JMS
interoperability. It would certainly be possible to support full 0-9 on
the trunk, but as I said above there is really no tangible benefit other
than we could say we're being sorta but not really pedantic about trunk
compliance.
[...]
The point of compliance is that it allows users to use implementations
of the same spec version from different sources in the same system. I'm
not advocating that we adopt a pedantic, legalistic view of compliance
that impedes development while the spec as well as the implementation is
in flux. However I do think it is important to be clear about what users
can expect if they do decide to try to mix different implementations.
One obvious benefit of an implementation of the 0-9 'core' spec would be
that a user could deploy it in a system in which there were other
implementations of that protocol[1]. I can't say whether this benefit
would be realised by anyone or whether it would be worth the effort or
not. So to me the issue is less about being pedantic about policy and
more about trying to anticipate what users might want (never easy!).
[1] Another benefit might be that other implementations can use some of
our code to validate or bootstrap their own implementations of the 0-9 core.
- Re: AMQP 0-9 support Gordon Sim
-
