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.
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
