qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: C++ 0-9 merge heads up
Date Tue, 06 Mar 2007 15:58:46 GMT
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 :-)

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.

All my opinion only, of course :-)

-- Rob

On 06/03/07, Gordon Sim <gsim@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > I didn't think that change 'extra' spec change would affect the C++ as
> > it is only required if nowait is false.
>
> Almost all changes to a spec file will affect any implementation that
> uses that spec file. Even adding an unused parameter to a method has an
> effect - for c++, any client or broker built against that will require
> that parameter to be specified or else a decoding error will occur.
> Whether it breaks anything (beyond interoperability) is a separate
> question.
>
> As nowait is false by default, any piece of code not explicitly updated
> to set the new parameter to true will require a response. The python
> client waits for responses if they are to be sent, resulting in the test
> hanging if the broker doesn't respond as expected.
>
> I'm not jumping on this case only, and I know this has been discussed
> before, but I think we must be very careful about modifications of the
> spec file.
>
> For one thing I'm not sure how that works with the copyright on the top
> of those files; are we allowed to make changes to this file? do we need
> to make those changes clear in some way?
>
> Another issue is that when we come to creating releases our
> implementation is non-compliant. This is different (and worse in my
> opinion) than merely not implementing everything or adding extra
> functionality. Again, I'm not sure what the legal position is w.r.t
> releasing AMQP 'implementations' with altered methods.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message