Rupert,
comments inline.
On 7/31/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
>
> I think this is heading in the right direction ;)
Cool, so we are in agreement here :)
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.
[RA] Like I said that was just a starting point. That interface will
definitely be reworked just like the receiving side.
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?
[RA] You got that right. Did u notice that the Invoker and Delegate are in
common?
Also there is a CommonSession class, Connection and Channel class in
common?
The idea is that the comm stack is common to both broker and cleint !!!
Simillar to a ClientSession there will be a ServerSession.
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'.
[RA] Exactly. Sorry I didn't get to the point early. I am truly sorry it
took so many emails for us to get an understanding.
The API is only a mask 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?
[RA] Certainly a possibility if the Struct interfaces are used.
In certian instances the API uses generated code.
For example the Option class is generated.
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.
[RA] Thats actually a very good point. A nice optimisation.
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.
[RA] Yes the only draw back apart from that, is the application code will
have to instantiate a specific StructFactory(version specific). - which is a
very minor issue.
Since we are using the Struct Interfaces the rest of the code remains static
between versions.
Also as u pointed out it kinda makes the API a bit unatural which is not a
huge issue. I guess people like simple arguments in an API.
But I woudn't count out the above approach entirely.
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
> > > > >
> > > >
> > >
> >
>
