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
