For me, I would be hiding the version of the protocol as much as possible
(since this is essentially only "discovered" in the negotiation between
client and server when a connection is initiated - not at coding time).
Therefore you need to be programming against an API which is (reasonably)
version agnostic. How would I know whether to call the 0-10 or the 0-11
createQueueDeclare( ... ) method?
We have to assume a certain level of commonality between protocol versions
for any true multi-version spport to be possible.
For this to work, I would think interface MethodFactory_v0_11 must extend
MethodFactory_v0_10 ... so that I, as a programmer could be given a method
factory and rely on it having the createQueueDeclare method which takes the
0-10 arguments...
Not sure I'm making sense... just back from vacation :-)
-- Rob
On 01/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
>
> Roughly:
>
> interface MethodFactory_v0_8
> {
> QueueDeclare createQueueDeclareMethod(v8 args...);
> ... more
> }
>
> interface MethodFactory_v1_0
> {
> QueueDeclare createQueueDeclareMethod(v10 args...);
> ... more
> }
>
> interface QueueInvoker
> {
> queueDeclare(AMQPSession context, QueueDeclare qd);
> }
>
> interface QueueDeclare
> {
> // Fully opaque interface.
>
> // Or expose args that we are sure will be common amongst all versions,
> e.g.
> String getQueueName();
> }
>
> class QueueDeclare_v10 implements QueueDeclare, Struct
> { ... }
>
> class QueueDeclare_v8 implements QueueDeclare
> { ... }
>
> class QueueInvoker_v8 implements QueueInvoker
> {
> queueDeclare(AMQPSession context, QueueDeclare qd)
> {
> // Ensure context and command are v8
> if (!(context instanceof AMQPSession_v8) || !(qd instanceof
> QueueDeclare_v8))
> {
> throw new IllegalArgumentException();
> }
> }
> }
>
> Similarly for QueueInvoker_v10
>
>
>
> On 01/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> >
> > I think it would be best not to 'reveal' Struct in the API itself.
> > Partially or fully opaque method wrappers and a versioned factories for
> > creating the method calls would hide the version specific
> implementations. I
> > think I will have to post an example to explain what I mean by that...
> >
> > On 01/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
> > >
> > > Just to be clear... the multi version support and references to
> > > "structs" is
> > > about 0-10 and onwards... This design is based on the new protocol
> > > features
> > > that are evolving as part of 0-10 (e.g.
> tracks/sub-channels). Backward
> > > compatability with versions prior to 0-10 will be have to be achieved
> > > some
> > > other way... yes?
> > >
> > > -- Rob
> > >
> > > On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Folks,
> > > >
> > > > The following link contains the design concepts behind the new
> client
> > > (and
> > > > the java broker)
> > > >
> > > >
> > >
> http://cwiki.apache.org/confluence/display/qpid/Restructuring+Java+Broker+and+Client+Design
> > > > This is an evolving document and is intended as useful base to start
> > > work.
> > > >
> > > > Hopefully this will help everybody during the discussions.
> > > >
> > > > Regards,
> > > >
> > > > Rajith
> > > >
> > >
> >
> >
>
