Robert Godfrey wrote:
Addressing these points in a random order:
1) Changing the spec file:
I think we should ensure that all our changes are in a separate XML file
from the official AMQP spec. We can then overlay these on top of the
official spec at code generation time. There is some ability in the code
generator to do this, but as to whether it would work for the case of
replacing a method with a new version with an extra argument, I would have
to find by experimentation :-)
The generator on the 0-9 branch was altered to allow exactly that and it
does allow the addition of arguments for methods. I agree thats a nice
way to go as changes become more visible and more manageable.
2) Interoperability
I think we should do our best to guarantee that any change that we make
will
not stop an AMQP compliant client working correctly with our broker. That
is no new arguments (unless they are bits which default to false in methods
which already have bitfields)... no new contracts (i.e. that a client must
sent command Y whenever the broker sends command X).
Our issue is that there are things in the AMQP spec which are unclear or
cannot be implemented safely without the addition of extra methods. On
alternative would be to implement a parallel method (lets say, rollback2 or
recover2) which has the extra method. This would obviously require some
duplication of handler code on our part, but would not be so fundamentally
non-compliant with the spec.
Our particular problem here is that we *know* that the spec in this area
will be changing, so there is no point lobbying for a spec change.
I agree and am not saying that we should never ever change the spec
file, just that we should do so cautiously, and aim to minimise
interoperability and compliance issues.
In the particular case of recover the method is so underspecified that
the chances of interoperability are arguably pretty low anyway. Again,
different interpretations of a vague aspect of the standard reflect less
badly than do changes resulting in crashing channels.
