Hi Martin, Many thanks for you comments.
> Arnaud, > Thanks for putting that document together. I haven't been keeping up > with the 0_10 work as much as I'd like but with M2 coming to an end > I'll have to dive back in there. I would very much like to request > that we think about supporting 0_8 *and* 0_10 in the client code at > least. This could be by having two sets of classes below the model > layer such that the client can only speak one protocol at a time. This > would be beneficial for migrating existing customers to the newer > protocol. Deployed clients are generally harder to change then their > broker so if the client could support both protocols an incremental > upgrade could be possible. I am not sure of the benefit of that as the 0.8 protocol is not compatible with 0.10, a 0.8 client cannot talk to a 0.10 broker. As you said it is usually more difficult to get all your clients migrating to the new protocol then it would make more sense to have the broker using two addresses i.e. one for 0.8 and a new one for 0.10 clients. Then you would be able to smoothly migrate your clients to 0.10 when the 0.8 ones are still running. An important thing to consider though is that the model layer has also changed. Thus, I am not sure having a broker or a client compatible with the two protocols could easily be achievable. > As we are designing the changes for 0_10 I think it is important to > think about multiple protocol version support. Ideally going forward > from 0_10 the protocol (from what I understand) will not have such > radical changes as we have going from 0_8 to 0_10, as such supporting > 0_11 etc from our next client should be one of our goals. Version control is indeed important and I really think that it should be on our face to face agenda. However, it does not only depends on the implementation design but also on the 0.11 specs. > If we do decide to support 0_8 as well the next client we will of > course have to remember that the project has people using this > software in production. As a result we cannot just change our client > API. New functionality is easy to add but altering the behaviour of > existing methods will be extremely annoying to existing users. All > changes to existing APIs should be well documented and have the > ability to maintain their functionality in the selected protocol > version. Ideally current clients should be using the JMS interfaces so > reducing the change problem but we shouldn't assume this. As we move > forward with the implementation we could start to think about what > methods that are public in our client code that should actually be > public and part of any API we wish to put forward. Introducing an AMQP API is part of the work that Rajith has started. We have also to discuss that at the AMQP level as it impacts all implementations. I think that it is going to be a 0.11 focus. I would say that we can achieve 0.10 support before that though.
