I think this is heading in the right direction ;)
I'm not sure about the need for a MessageSender (especially not one bound to
a queue!). At this level it would seem quite suitable just to call
methodTransfer.
Also worth noting is the reverse symmetry of the Invoker/Delegate
interfaces. Delegate is the incoming interface for the client, but the
outgoing one for the broker. Might it be possible to use the same interfaces
in both, albeit from opposite perspectives?
I can understand why the Invoker/Delegate include all methods in all
'classes' in the protocol. It makes it easier to write the stub, and
provides version specific implementations that only respond to the methods
relevant to a version.
We can work out what is the best way to present the methods as an API, all
in one big class/interface seems too unweildy. So I think you are doing the
right thing, filtering to expose the methods by 'class'.
One big difference between the outgoing and incoming interfaces, is the way
method arguments are presented.
In ClientSession:
public void messageBody(byte[] src) throws QpidException
In SessionDelegate:
public void queueBind(Session session, QueueBind struct) {}
The arguments are exposed directly in the ClientSession one, but as opaque
structs in the incoming one. For the reasons I gave earlier, about the
possibility of wrapping direct buffers, and exposing method structs as
opaque interfaces on top of them, might it be an idea to make the outgoing
interface take strucs as arguments instead?
A quick example, supposing I receive a message as a MessageTransfer struc. I
could send it back out again as a MessageTransfer struc. If the struc is
really a wrapper on a byte buffer, no or minimal decoding/recoding could be
done on the buffer.
This is just an idea, it makes the API somewhat less wieldy, by requiring
the use of a factory to create strucs before calling methods. But more
flexible as the same factory interface can be used, that provides versioned
strucs.
Rupert
On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
>
> 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
> > > >
> > >
> >
>
