One other thing. We'll be sending real business over the 0-9 (non-WIP) protocol. We want to be very very sure that the WIP transport has been thoroughly tested before running it for real.
That burden of proof should fall on the branch, imho. John On 23/01/07, John O'Hara <[EMAIL PROTECTED]> wrote:
To be 0-9 compliant, you have to support the 0-8 framing by default. We can't ship at all if we're not compliant..... eating own dog food and all that! Clients have to connect as version 99-0 to get the WIP framing. If that in itself does not resolve the connection issue, then an errata to enable that detection should be added to the spec. Cheers John On 17/01/07, Kim van der Riet <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-01-17 at 13:11 +0000, Robert Godfrey wrote: > > Are you saying we will not support those parts of 0-9 which are also > in 0-8 > > (i.e. Basic, File and Stream)? > > > > As far as I understand it, those are still in the spec although marked > as > > likely to be replaced. If we are claiming spec compliance should we > not > > still support these classes for the moment? If spec compliance is not > our > > goal (i.e. we are really anticipating a later version of the spec > where > > these elements have been removed) we should be clear about that. On > other > > threads we have been quite reluctant to get "ahead of the spec". > > > > - Rob > > IIRC, there are some difficulties in supporting both at the same time - > issues that the protocol does not resolve. For example, framing: When a > ProtocolInitiation is received by the broker, how does it know whether > to use the new request/response framing or old MethodBody frame to send > the Connection.Start method? > > However, your question on how we label an implementation that supports > only 0-9 WIP is valid. It cannot be strictly 0-9 compliant, so perhaps > we should call it 0-9-WIP compliant instead. > > Kim > >
