Re: AMQP 0-9 support

[Steve Vinoski]

I've been off on another mission for awhile and so have been silent  
on this issue thus far. However, I'd like to chime back in and say  
that I disagree with Carl that "the trunk should represent our  
forward development," if by that he means that the trunk should  
contain experimental and unproven features and functionality. I  
believe we already break the trunk too much as it is -- I've seen  
several cases recently where the Java trunk didn't even compile,  
which is never good. The plan suggested a few weeks ago to do 0-9  
work on trunk, thereby breaking it for "a week" (which almost  
certainly would have turned into 2 or more weeks) would have been a  
huge mistake IMO. As I said before, large items of work that cause  
major churn, like 0-9 and like persistence, belong on a branch.

The model we used for M1 worked reasonably well. The Java trunk was  
active and yet rarely broken for M1, and once we got to the point  
where we decided it was functionally complete, we created the M1  
release branch and finished it. That branch also serves as a "fixes  
branch" for the M1 release for the future, if needed. This same  
approach worked well for all the JMS work that followed M1 -- we  
didn't create a release branch, but again, the trunk was rarely if  
ever broken, yet at the same time it gained significant JMS  
functionality. Meanwhile, Robert Grieg was off also working on a  
persistence branch. Imagine if he had insisted on dragging half- 
working persistence code onto trunk instead -- it would have  
adversely affected every single user of trunk, whether they were a  
committer or not, and would have significantly jeopardized the JMS work.

So again, development items that cause significant disruption and  
churn, such as the maven switchover, persistence work, and protocol  
changes like 0-9, belong on a branch until stable, at which point  
they should be merged.

More comments below.

On Jan 23, 2007, at 11:18 AM, John O'Hara wrote:

That's fine in principle if the trunk will fully support 0-8  
transport and
WIP transport; in compliance with agreed 0-9 spec.

If the new code is 0-8 only, that's too big a risk to swallow without
proving it all out on the branch first.
If we want to make changes to the WIP transport, as may be  
suggested by the
recent lobbying by Cisco and iMatix, then we shouldn't be  
committing that
level of churn to the mainline.

+1

We need to reach some agreement on this.
Myself and Robert are worried that dropping the 0-8 transport from  
trunk at
this point will cause lots of immediate issues which prevent  
development of
other important functions like improved persistence and fixing  
errors in TX
handling.

+1

--steve

Can you suggest a way forward that mitigates my concerns here?
John

On 23/01/07, Carl Trieloff <[EMAIL PROTECTED]> wrote:


John,

I would not really agree, the trunk should represent our forward
development. If we want to create
stable releases, these should be done with a branch. It might even be
worth releases the branch as a M2.

I was able to meet with a few other long term apache members last  
week
while in business and asked about
creating branches for use as stable versions when project members  
needed
them and that did not align with the
release cycle if the main project. This is done on other projects and
from what I can tell is accepted practice.

Regards
Carl.

John O'Hara wrote:
> One other thing.  We'll be sending real business over the 0-9  
(non-WIP)
> protocol.
> We want to be very very sure that the WIP transport has been  
thoroughly
> tested before running it for real.
>
> That burden of proof should fall on the branch, imho.
>
> John
>
> On 23/01/07, John O'Hara <[EMAIL PROTECTED]> wrote:
>>
>> To be 0-9 compliant, you have to support the 0-8 framing by  
default.
>> We can't ship at all if we're not compliant..... eating own dog  
food
and
>> all that!
>>
>> Clients have to connect as version 99-0 to get the WIP framing.
>> If that in itself does not resolve the connection issue, then an
>> errata to
>> enable that detection should be added to the spec.
>>
>> Cheers
>> John
>>
>> On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> wrote:
>> >
>> > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote:
>> > > Are you saying we will not support those parts of 0-9 which  
are
also
>> > in 0-8
>> > > (i.e. Basic, File and Stream)?
>> > >
>> > > As far as I understand it, those are still in the spec  
although
>> marked
>> > as
>> > > likely to be replaced.  If we are claiming spec compliance  
should
we
>> > not
>> > > still support these classes for the moment?  If spec  
compliance
>> is not
>> > our
>> > > goal (i.e. we are really anticipating a later version of  
the spec
>> > where
>> > > these elements have been removed) we should be clear about
that.  On
>> > other
>> > > threads we have been quite reluctant to get "ahead of the  
spec".
>> > >
>> > > - Rob
>> >
>> > IIRC, there are some difficulties in supporting both at the same
>> time -
>> > issues that the protocol does not resolve. For example, framing:
>> When a
>> > ProtocolInitiation is received by the broker, how does it know
whether
>> > to use the new request/response framing or old MethodBody  
frame to
>> send
>> > the Connection.Start method?
>> >
>> > However, your question on how we label an implementation that
supports
>> > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so
perhaps
>> > we should call it 0-9-WIP compliant instead.
>> >
>> > Kim
>> >
>> >
>>
>