> > 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.
As I pointed out in the previous emails. The API expose everything except for the connection negotiation and failover. And have added a few convenience methods for message handling. I don't understand what is not low level about it? The API has the same level of granularity as the com layer except for connection negotiation and failover. Do u envision users wanting to do all that? 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. Again I am confused as to what you want. The MessagePartListener exposed message content Frame by Frame using the data method ? What more do you want? What do mean by not everything? What are these methods? Can you please provide concreate examples? Lets start it from there. 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. > > > > > > > > > > >
