Rupert, Martin and Greig
Looking at the code below I see that you have understood our approach.
Thats the way we are doing it.
Let me explain some background that will clear some of the misunderstanding.
The current API is very much work in progress and thats why Arnaud labeled
it as temporary.
We needed a base to work with and as a start Arnaud and I came with an API
close to JMS.
By any means that is NOT the final API. We are refining it as we work
through our implementation.
You can see that we are slowly refining it and now it's looking closer to
the "low level API" you are talking about.
However I don't like to label it as a low level API, bcos of the subtle
differences I highlighted using my previous email.
I also think we all agree that we need a Qpid API that looks like the
protocol? Do we have any disagreements here?
I also don't buy the arguments about performance being impacted by layering.
The previous client also had these layers allthough it wasn't visible due to
very tight coupling.
Regards,
Rajith
On 7/31/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
>
> Quick example:
>
> public class CommonSessionDelegate extends Delegate<Session>
> {
> public void sessionAttached(Session session, SessionAttached struct)
> {}
> public void sessionFlow(Session session, SessionFlow struct) {}
> public void sessionFlowOk(Session session, SessionFlowOk struct) {}
> public void sessionClose(Session session, SessionClose struct) {}
> public void sessionClosed(Session session, SessionClosed struct) {}
> public void sessionResume(Session session, SessionResume struct) {}
> public void sessionPing(Session session, SessionPing struct) {}
> public void sessionPong(Session session, SessionPong struct) {}
> public void sessionSuspend(Session session, SessionSuspend struct) {}
> public void sessionDetached(Session session, SessionDetached struct)
> {}
> }
>
> I can't find the Invoker interface, so I'll just guess what it might be
> like:
>
> interface Invoker<Session>
> {
> public Session sessionOpen(SessionOpen struct);
> public void sessionFlow(Session session, SessionFlow struct);
> public void sessionFlowOk(Session session, SessionFlowOk struct);
> public void sessionClose(Session session, SessionClose struct);
> public void sessionClosed(Session session, SessionClosed struct);
> public void sessionResume(Session session, SessionResume struct);
> ... and so on.
> }
>
> Really not bad as a low-level API. Allows for different 'Session'
> implementations for different versions of the protocol. Allows for
> different
> struct formats for different versions of the protocol.
>
> There is also something I like about passing the arguments in structs,
> rather than directly as arguments, which is that struct's can completely
> hide their implementation. Could be held in Java fields, could just
> contain
> a 'pointer' into a raw direct byte buffer. Keeps the way open for having a
> native implementation where direct byte buffers are managed natively.
> (Incidently I've been writing a prolog virtual machine in Java and C, I
> pass
> byte code in direct byte buffers from a compiler in Java to the virtual
> machine in C and it is a very good way of getting good performance over
> JNI.
> There is also the fairly well known 3d flight simulator, using Java and
> native C OpenGL calls, using direct byte buffers, for good performance 3d
> rendering from Java)
>
> All thats really needed to make this usable, is default code for the
> ping/pong cycle, obeying flow requests, and so on, and some convenience
> code
> to execute the common connection start, secure, tune, open conversation.
> Code written against this API to extend or otherwise hook into the
> delegate,
> to be notified of all protocol events, override/handle those that it is
> interested in. Something akin to the Interceptor pattern is the first
> thing
> that comes to mind...
>
> Rupert
>
> On 31/07/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> >
> > On 31/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I think that all agree about having a Qpid API. Now we may not agree
> > > about the granularity level of such an API. I like to make several
> > > points clear so we all speak about the same thing:
> > > - We have introduced a common communication layer that will be used by
> > > both broker and client implementations. I think that we all agree on
> > > that layer.
> > > - The aim was to isolate the JMS layer from this communication layer
> for
> > > three main reasons: for shielding the JMS layer form specification
> > > changes, for simplifying concurrent development efforts and for
> > > achieving a certain level of plugability of our JMS layer.
> > > - On the client side this communication layer has been exposed to the
> > > JMS layer through what we call a Qpid API. This is the point where we
> > > don't agree and the debate is about the granularity of this API.
> > >
> > > This API is currently a convenient way of isolating those three layers
> > > and is NOT fixed. We however need a certain level of stability if we
> > > want to eventually deliver a 1.1 client. So, the approach we went for
> > > was to define a simple API that we would refine when developing the
> 1.1
> > > client code base.
> > >
> > > I think that we all agree that this is a good thing to expose a
> specific
> > >
> > > QPID API even if THIS API does not have to be exposed as if. Another
> API
> > > can be exposed on top of the communication layer and the current
> > > interface can be kept private and only seen as a convenient way of
> > > implementing JMS.
> > >
> > > So, all what I am saying is that we really need this debate and I
> > > appreciate very much Rupert and Martin concerns about the current Qpid
> > > API. But, this API is not finalized and can be replaced by another one
> > > that is closer to the protocol (the current one would therefore be
> seen
> > > as a convenient layer on top of the communication layer).
> > >
> > > Arnaud
> >
> >
> > I was under the impression that the proposed API was the proposed Qpid
> API
> > to be exposed as our published API. So thanks for explaining that it is
> of a
> > temporary nature.
> >
> > Points above accepted, but if you are going to change this API, and it
> is
> > what the JMS layer is built on top of, then it follows that the JMS
> layer
> > will have to change, as it changes. So the isolation of the JMS layer
> from
> > change, is negated by the argument that the proposed API is temporary.
> >
> > One of two things will happen, either what was proposed as a makeshift
> > solution will become permanent, or the API and therefore the JMS layer
> will
> > change too. I think that, especially if this API is implemented in all
> > languages, the first option is far more likely to be followed; it will
> be
> > too much effort to change it and attrition will set in.
> >
> > So how about working out what the low-level API will be now? The thing
> > about APIs is, you rarely get more than one shot at designing them, and
> > designing a really good one is not easy. Lets make damn sure we get it
> > right.
> >
> > On the other hand, if there is an absence of time and will to work out a
> > low-level API to expose now. You may as well put the JMS layer right on
> top
> > of the comm layer anyway, seeing as it is only going to have to change.
> >
> > Right now, I'm looking at the API and thinking that its more of a
> > 'nuisance' layer to implement JMS on top of (particularly translating
> > exceptions, ugh), than a 'convenience' layer. On the other hand, the
> comm
> > layer is intuitive and looks as though it will stand up to usage accross
> > different protocol versions. You pass in frames at the bottom and get
> method
> > calls out the top, or pass in method calls at the top and get frames out
> the
> > bottom. I think I would be very tempted to focus on the Invoker and
> Delegate
> > interfaces, as a good starting point for fleshing out a low-level API.
> >
> > Also, I think that the requirement to isolate against change is a bit of
> a
> > red herring. The protocol is not evolving so rapidly that we cannot keep
> up,
> > and when the protocol does change, it could be in semantically subtle
> ways
> > that we cannot isolate ourselves from anyway. Best way to isolate
> against
> > change is to use solid bottom up OO design, imho. Then at least you
> always
> > have good code to re-use.
> >
> > Rupert
>
