Yes, it certainly sounds like the same idea. I don't think I can see SessionClient yet, probably not checked in.
On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > 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 > > >
