qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: AMQP 0-9 support
Date Thu, 18 Jan 2007 00:39:42 GMT
Robert Godfrey wrote:
>>
>>
>>
>> Why not? The WIP portion of the spec is essentially a refactoring of
>> basic, stream, and file + additional framing level changes to support
>> HA. The broker should be able to be fully as functional as it is now
>> (more functional hopefully) without using basic.
>
>
>
> I wholeheartedly agree that we expect the functionality to be better once
> the spec is complete and implemented.  I guess my issue is that 
> currently we
> (as in where I work) are aiming to deploy builds based on stable cuts 
> of the
> trunk code.  I may be being overly nervous here, but we seem to be 
> moving to
> a place where trunk does not comply to any version of the spec only to
> pieces of the 0-9 spec that are explictly marked Work In Progress.  
> Further
> if we remove the 0-8 like parts we do not have anything to fall back 
> on if
> we find conceptual bugs in the 0-9 WIP (not saying it's going to 
> happen, but
> as you say it is a proof of concept at the moment).
>
> I think our concerns may differ because of the different positions we are
> in, and I hope I do not mis-represent your position here... I am 
> looking to
> support applications already in (or about to go in to) production with
> QPID.  You are looking to the future and the functionality we need to 
> have
> to support a wider range of use cases.  I don't want to lose the 
> current 0-8
> like functionality until it can be proven to be superceded by the 0-9 WIP
> stuff.  You want to prove that the 0-9 WIP work supercedes the 0-8 style.
> My take was the reason that the 0-9 protocol included both the 0-8 and 
> the
> WIP styles was to allow a period of transition and to allow us to 
> shake out
> any problems with the 0-9 WIP protocol.
>
>
>>
>> We could do that, but that would be more work with no benefit other than
>> to be able to say we officially conform to the spec, which I don't think
>> we can say in any meaningful way at this point anyways.
>>
>> Also, Qpid is supposed to be the proof of concept implementation that
>> allows the 0-9 WIP stuff to become the 0-10 version of the spec, and so
>> one of the things we need to demonstrate is that we won't actually be
>> losing functionality by removing basic, stream, and file, and the
>> easiest way to do that is to actually remove them.
>
>
> I've absolutely no objection to a branch build with the 0-8 stuff turned
> off... I would just prefer to see a spec compliant build on trunk.  
> Although
> the possibility may be remote, I do not think that we should remove 
> the 0-8
> style on trunk until that becomes official AMQ spec, otherwise we will 
> be in
> a difficult position if the AMQ committee does not agree on moving 
> forward
> with the WIP protocol, or if there are major revisions to it (again - I
> think that is unlikely, but we should not take anything for granted).
>
> I'd really like to get some other people's input here, but my desire 
> would
> be that we attempt to keep trunk as compliant as possible with at most us
> having enhancements *over* the spec, not choosing to not implement large
> parts of it.  If we wish to simultaneously use a branch to demonstrate a
> proof of concept that the protocol without Basic etc is sufficient, I 
> think
> that is great.  Therefore if it isn't easy to properly implement 0-9 as
> written, then perhaps we should skip 0-9 compliance.  On the branch we 
> can
> do a proof of concept for 0-10, and on trunk we can keep on 0-8.  If 
> we can
> properly conform to 0-9 then that should be on trunk, with proof of 
> concept
> for 0-10 simply being to turn off Basic etc...
>
> - Rob
>

If it is inevitable that we will move to 0-9/ 0-10 etc and the way the 
spec is going why should it not be truck. We would want the trunk to 
track where the spec is going and then we create a branch to support 0-8 
which is just one frozen version in time. Given that there are other 
merges on trunk for JMS for example that are not compliant and being 
worked by the spec group why should they not all be truck?

The requirement for stable sets of functionality for production should 
not be met by the trunk as that will highly hamstring the forward 
progress of the project. Under that reasoning cluster or persistence or 
any other work should also not be merged to trunk. Thus, I have no 
issues creating a snapshot, and even helping maintain it or branch until 
we get to the next deployable point on the trunk. I think we need to 
make sure that we can progress the project and make sure that our users 
and those wanting to deploy can get stable versions. I think that we 
might want to create a branch snapshot for deployments now, and then 
plan a stable release of the project towards the end of the quarter 
which can co-inside with 0-10 spec release and be as close to compliant 
with that as possible

Thoughts...
Carl.



Mime
View raw message