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