qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: AMQP 0-9 support
Date Thu, 18 Jan 2007 01:04:56 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 didn't say 0-9 WIP was a proof of concept. I said the Qpid 
implementation of it is supposed to be a proof of concept. I fully 
expect we will find gaps in the 0-9 portion of the spec, the same way 
we've found gaps when trying to implement JMS over 0-8. That is 
precisely the reason it is labeled WIP, because it has no implementation 
yet. I believe we are fully expected to implement any extensions 
necessary to support the required functionality, and those extensions 
will be incorporated into 0-10.

> 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.

Just to be clear there will be no feature regressions required to 
support 0-9 WIP, it will in fact be quite the opposite, since the 0-9 
WIP protocol will enable us to support features we don't currently have, 
and as I mentioned above we are expected to extend the protocol where 
necessary in order to avoid regressions, so all in all there will be a 
more limited set of features available to 0-8 clients, so the only 
reason I can see for us to keep basic is if we want to choose right now 
to start being pedantic about spec compliance.

>> 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).

It would certainly be possible to support both versions, however in my 
view this would be a waste of time. The only circumstance under which 
this would help us is in the *extremely* unlikely event that the working 
group decides to entirely remove the WIP portions for 0-10 and regress 
the protocol to 0-8, and even then we might as well wait until that 
point to do the work since it wouldn't be significantly more difficult 
then than it would be right now.

> 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...

I think the trunk should reflect the direction the spec is moving, which 
is in this case towards the 0-9 WIP, as well as towards JMS 
interoperability. It would certainly be possible to support full 0-9 on 
the trunk, but as I said above there is really no tangible benefit other 
than we could say we're being sorta but not really pedantic about trunk 
compliance.

As for the difference between enhancements *over* the spec and "choosing 
not to implement large parts of it." I believe it is well understood 
that the 0-9 WIP is intended to supersede basic in 0-10, so I don't 
believe it's as bad as arbitrarily choosing not to implement large parts 
of the spec.

--Rafael

Mime
View raw message