qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: Use of AMQShortString in client side code
Date Wed, 19 Sep 2007 12:07:50 GMT
Robert Godfrey wrote:
> OK - let's try to examine this in detail...
> 
> The objection to using AMQShortString is, I presume, as much aesthetic as
> anything else.  We want to provide through the Java API a type which is
> natural to the Java programmer.  [As an aside, I presume therefor that where
> the argument is a Field Table you wish to allow the programmer to pass in
> any valid Map implementation].

At a minimum it would be nice if FieldTable implemented the Map 
interface and had a copy constructor that took a regular Map.

> AMQShortString (which should have a length <= 255 check in it, I admit)
> represents the type that is sent down the wire.  In the same way the
> FieldTable class represents what an AMQPFieldTable is.  Where the object
> never escapes the qpid library we do not want to convert this into a String
> (nor convert our field table into a general purpose map).  Only at the
> interafce between our internal library and the calling application do we
> have an issue.   Here we have a choice

This analysis gets a little more complicated in 0-10. In 0-10 a frame 
boundary can appear anywhere, so it isn't possible to simply wrap the 
bytes read in off the wire in an AMQShortString object and pass that up. 
You either need to copy the bytes into a newly allocated ByteBuffer, or 
have a more sophisticated AMQShortString implementation that operates on 
a list of fragments. Obviously it is impossible to do the latter if 
AMQShortString is used directly throughout the code.

> 1) we can always hide our internals and present an interface that simply
> uses the Java types
> 2) we can have an API which is purely in terms of our AMQP domain objects
> and makes no concession to Java idioms
> 3) we can present an interface that explicitly offers the programmer the
> choice
> 4) we can present an interface defined in terms of common interfaces that
> both the AMQP domain types and the Java types implement
> 
> 
> If you believe 1) the you should necessarily also believe that we should
> only be producing a JMS interface as you have no desire to program to AMQP
> but only to Java conventions :-)

I actually do want to expose a non JMS interface that doesn't use 
AMQShortString. There is a lot of ground between providing an AMQP 
specific messaging API and providing an AMQP specific String API.

> 2) is ruled out by our need to implement JMS
> 
> 3) requires double the number of methods in the interface
> 
> 4) requires the library to be full of code such as
> 
> if(parameter instanceof AMQShortString)
> {
> ...
> }
> else
> {
> ...
> }

Why would the library need to be full of code like this? The interface 
AMQShortString presents is just a CharSequence. The only place that 
would need to know the difference is at the point of encoding/decoding. 
When decoding we would always construct the more efficient impl of 
CharSequence that directly wraps a ByteBuffer or a list of fragments as 
the case may be. When encoding we could just use the CharSequence 
interface since you need to copy anyways, or if there was some 
optimization necessary we could dispatch to type specific codecs.

> Personally I'd be more inclined to go for option 3 because it makes explicit
> the options that the programmer has.
> 
> There should be no need to convert the short string into a string multiple
> times.

If I knew what the choice was I might be inclined to agree, however it 
seems like the choice we'd be offering is between one concrete impl of 
CharSequence and another concrete impl of CharSequence. Am I missing 
some aspect of the AMQShortString interface that we depend on that isn't 
part of the CharSequence interface?

--Rafael

Mime
View raw message