Yes I believe the Qpid API sits above the API you talk about. And I would like that to be the API we promote to users as a client.
What you are essentially talking about is a slightly different approach to how the comm layer should expose it self. We need that API for sanity and design purposes. End users may also use it if they want to build their own client or broker. So lets not confuse that with the Client API discussion. I believe Rafi can answer you better as to why he didn't use the interface approach or as to why he didn't split into seperate classes. Also I am not sure spliting up server and client chasis make much sense. Bcos a broker can be a client to anothe Broker. Can u elaborate a bit more as to why you would need to make such a distinction. I think an Invoker and a Delegate makes more sense. Invoker being the methods you can call and Delegate being the method that somebody else can call you with out making any distinction as server or client. On 8/21/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Yes, but my proposal differs slightly, in that it uses interfaces, not > concrete classes, and splits server and client chassis up. Other than > that, > yes, the comm layer seems to fit the bill perfectly. No surprise, given > that > I started with Rafeal's stub and pulled an interface only API out of it. > > On 21/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > On 8/21/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > > > On 21/08/07, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > > > > > > > Watching the debate, I think you guys are actually quite close to > each > > > > other. > > > > > > > > > Yes, as I say, we are to some extent talking at cross purposes. I'm > > > primarily coming from the point of view of modularizing, and allowing > > > multiple implementations of a common set of interfaces. I think Rajith > > is > > > primarily looking at things from the point of view of offering a > client > > > API. > > > I'm actually thinking of an API that is for both the client and the > > > broker, > > > to call into a shared comm layer. > > > > > > Rupert, there is code in common module that satisfies your criteria > > a.k.acomm layer. > > I guess we can disucss this more in detail when we all meet at the f2f. > > The idea is to have a common API that will provide a basis for a client > > and > > broker implementation. > > If a user wants to hook into this layer, then that is possible as well. > > > > The client API that I am talking about is a thin layer on top of this > > common > > API. > > Which provides connection negotiation, failover and a few convinience > > methods. > > 90% of the method invocations are directly called on the comm layer. > > If u look at the code. > > ClientSession implements o.a.q.client.Session extends > o.a.q.Sessionextends > > Invoker. > > > > The o.a.q.Session is part of the comm layer and will be used by both > > broker > > and client. > > The o.a.q.client.Session is just a mask for exposing only what is > > appropriate and useful for a client + sugar. > > > > So we seem to be in agreement. > > > > > L1 - Transport > > > > L2 - Session > > > > L3 - Execution > > > > L4 - Model > > > > > > This is something for me to think about, because I have not tried to > > take > > > this into account. My idea to expose the whole protocol, is completely > > > flat > > > wrt this layering. The reason I thought every method has to be > exposed, > > is > > > so that the client can be plugged direct into the broker in-vm or into > a > > > comm layer for going over the network. Sounds like I need to expose > > layers > > > 2-4 in full, in order to do this. > > > > > > Is it the case that every method belongs to one of these layers? In > > which > > > case, will the layer numbers be put into the 0-10 xml? > > > > > > Rupert > > > > > >
