On 17/01/07, Rafael Schloming <[EMAIL PROTECTED]> wrote:
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". Currently we don't actually support file and stream, just basic, so we won't really be in a different position with respect to spec compliance, we're just converting our basic support to message support. Personally I don't have an issue with getting ahead of the spec, I think we just need to be more careful about how we do it so that a) we don't break interoperability between the different qpid implementations at the very least, and b) so that we don't needlessly break compatibility with the spec when it would be just as easy to extend the spec, e.g. by choosing type codes for the new field table types that don't conflict with the spec defined type codes.
The conflicting type codes was just a mistake on my part. I took the proposal that Robert Greig had started and implemented it. Neglecting to check for conflicting types. Which of course there were with the 'S' type. Getting in the habbit of running the Python tests will help improve our interop.
Also, where we do consciously choose to go off spec it might not be a bad idea to have some sort of negotiation at connection initiation so that we can distinguish between plain vanilla clients and clients that understand our extensions. --Rafael
-- Martin Ritchie
