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: AMQP 0-9 support
Date Wed, 17 Jan 2007 20:27:47 GMT
>
>
>
> 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

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