qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Godfrey" <rob.j.godf...@gmail.com>
Subject Re: Use of AMQShortString in client side code
Date Wed, 19 Sep 2007 08:57:49 GMT
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].

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

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
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 :-)

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)

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

Hope this helps,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message