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.
