qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Qpid Java Design [ was Re: Proposed QPID API Discussion]
Date Wed, 01 Aug 2007 10:12:09 GMT
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 <rupertlssmith@googlemail.com> 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 <rupertlssmith@googlemail.com> 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 <rob.j.godfrey@gmail.com> 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 <rajith77@gmail.com> 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
> > > >
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message