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
