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