Yes, the current common layer, the stuff Rafael has been working on, looks very good to me. As I say, all I have really done is to split the invoker/delegate concept up into methods that client can call vs methods that broker can call, and to expose everything through interfaces rather than as concrete classes. That is, I have pulled out what I consider to be pure API. There is essentially very little difference other than that.
The advantage of using interfaces, rather than concrete classes, is that broker routing layer, can partially implement the comm layer, for direct client to in-vm broker. That's really the only difference. My comments are more directed at: http://cwiki.apache.org/confluence/display/qpid/Message+API+Design, which I don't feel is really the low-level protocol 1:1 API. Yes MessagePartListener exposes more, but not everything. I was hoping to see every method that the broker can call on the client, not just for 'message' but everything. Rupert On 16/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > Hi, > > It looks to me that the solution you are describing is very similar to > the current common layer (I am not speaking about the API described @ > http://cwiki.apache.org/confluence/display/qpid/Message+API+Design). > I would help (me at least) if you can highlight the main differences > between the two approaches. What would change, What are the advantages > of using your approach when compare with talking directly to the current > common layer? > > Thanks > > Arnaud > > On Thu, 2007-08-16 at 15:46 +0100, Rupert Smith wrote: > > Here is a picture that might help explain my idea more clearly. > > > > 'B' is the broker interface, callable by the client, 'C' is the > > methods the client handles, callable by the broker. Comm layer > > implements both, turning method calls into frames, frames into method > > calls. An instance of the comm layer created through its factory, will > > be specific to client or broker usage scenario. > > > > The broker routing layer also implements the protocol factory. As it > > is a broker it only supplies the broker interface, if you try and gets > > its client interface, it will throw an exception, which is why I put a > > line through the 'C'. > > > > As you can see, the client that is talking to the comm layer, could > > just as easily be talking to an in-vm broker. > > > > > >
