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
