Rupert, Can you try now. Sorry my bad for not checkin it in.
Regards, Rajith On 7/31/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > 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 > > > > > >
