qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++ 0-9 merge heads up
Date Tue, 06 Mar 2007 16:13:28 GMT
+1 - Kim can answer the question on the code generator.

On Tue, 2007-03-06 at 15:58 +0000, 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 :-)
> 
> 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
View raw message