I see your point and it reminds me that you did explain this before. Pointing it out on the dev-list was probably worthwhile anyway to make sure everyone is clear on the reasoning behind the choice.
Rupert On 29/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
The problem is that you can't translate an 0-8 message into a 0-10 message, they are completely different (different content classes and everything)... So if you are connecting to a 0-10 upgraded system, you have to speak 0-10; the broker really can't have a 0-8 client publishing messages, and then deliver them to a 0-10 client. So, whatever, you need the client to support multiple versions. It may also be useful to have the broker support multiple versions; but for me - since there is no translation - this is the same as just running a 0-8 broker and a 0-10 broker side by side... -- Rob On 29/06/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > I think Gordon has a point worth thinking over carefully in choosing between > putting 0.8/0.10 support in the broker or in the client, with respect to the > upgrade path of existing clients. Consider the following: > > Situation today: > > App1 0.8 Client -> 0.8 Broker -> App1 0.8 Client. > > 1. Putting 0.8/0.10 in the Client: > > App1 0.8 Client -> 0.8 Broker -> App1 0.8 Client. > / \ > New App 0.8/0.10 Client -> 0.10 Broker -> New App 0.8/0.10 Client. > > * Old clients cannot take advantage of improvements in the broker. > * We have to maintain two branches of broker code. > * If the 0.8 broker is completely discontinued, the old App1 will be forced > to upgrade. > > 2. Putting 0.8/0.10 in the Broker: > > App1 0.8 Client -> 0.8/0.10 Broker -> App1 0.8 Client. > /\ /\ > New App 0.10 Client -> 0.8/0.10 Broker -> New App 0.10 Client. > > * Old clients can upgrade to new client code in their own time frame. > * Old clients can take advantage of bug fixes in new brokers as a drop in > replacement. > * Old and new apps can share a single broker instance. > > Is making a 0.8/0.10 dual support broker significantly harder than doing it > for the client? > > Rupert > > On 29/06/07, Gordon Sim <[EMAIL PROTECTED]> wrote: > > > > Martin Ritchie wrote: > > > 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. > > > > "Deployed clients are generally harder to change" would suggest to me > > that what was needed was a _broker_ that supported 0-8 and 0-10, since > > not all clients could be upgraded when a broker is upgraded. > > > > When you say that it might be ok if "client can only speak one protocol > > at a time" do you mean a particular client process? If so, could that > > not be achieved simply by pointing it to a different version of the qpid > > libraries? > > > > If on the other hand the requirement is to allow a particular connection > > within a process to choose one of the two versions, that would not be > > quite as simple. If this is what you were thinking, do you have more > > detail on what the underlying use case would be? I.e. is it a client > > that needs to relay from one version of a broker to another? Or is it > > quite different parts of a system that just happen to be in the same > > process but might have different migration paths? > > > > I agree with your other points. > > >
