Rupert, By now you would have realized that the proposed API is actually a thin layer above the comm layer. For example check the SessionClient class. The SessionClient class extends CommonSession which extends Invoker (Invoker is a generated class with all the methods). The SessionClient class implements Session (The Qpid Session interface).
The API is actually a mask for exposing only Session related functionality from the Invoker. If you look at the WIP Session Client class u can see 90% of the calls actually called directly on the Invoker. I have also removed the MessageSender and replaced by protocol methods messageOpen() , messageTransfer, messageHeaders(), messageBody or Append and messageClose(). These methods will also be directly mapped to generated methods when the spec gets updated and will then completely disappear from the ClientSession class. The API is now looking very very close to the protocol albeit a few convenience methods. For example public void messageTransfer(String destination, Message msg) is only a convenience method (similar to what we have in python) The idea is to do as less work as possible in the ClientSession and leverage the generated code in Invoker. On the receiving side the delegates are like handlers. If somebody want to hook into method events, then simply extend the Delegate class (generated from spec) and implement the methods they like and pass that in the appropriate place in the comm stack. Is this close to what you are looking for? Regards, Rajith On 7/31/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > I also don't buy the arguments about performance being impacted by > > layering. > > > > I am prepared to accept that the performance will not be affected > noticeably > by layering, at least not on the client. On the broker, for small > transient > messages, resulting in CPU bound performance, it will contribute to the > load > undoubtedly. However, framing, threading, synchronization and many other > things will probably be a far greater consideration. > > I will say again, that I do like the way the comm layer hides the struc > implementations behind interfaces with a factory, keeping the path open to > the most efficient use of zer-copy direct buffers. The abstraction > presented > by the comm layer gets it just about right in terms of being at the right > level, owning an easily understood set of responsibilities, hiding an > implementation behind interfaces, and keeping open as many options as > possible both as the protocol changes and also to experiment with > improving > efficiency of implementations. > > I think it is a much better starting point for designing a low-level API, > than the proposed API. The proposed API is a superflous layer of jam in > the > sandwich. > > Rupert >
