Sorry Rob,;
Just skimming it again (wd06) and noticed
Section 3.1
locales - list (of strings)
TBH I'm not quite sure how exactly this is intended to be used it's only
actually mentioned in this table and it might be good to include an
example of the intended usage in the examples section.
That aside I'm afraid that it's another "illegal" List in the
application-properties of a message.
In 3.4.1.1
"The body MUST consist of an amqp-value section containing a list of
string elements"
That's certainly not illegal however from past experience (in QMF) using
lists for bodies isn't *entirely* the most amount of fun for JMS based
clients. You'll probably recall me whining about this sort of thing a
while back (my personal preference has always been to use ObjectMessage
for Maps and Lists because Lists aren't supported by specific Message
types and MapMessage doesn't use the java.util.Map interface).
As of 0.20 Lists can be exposed as a MapMessage!!??? the Object Keys are
the indices into the List. I personally loath and detest this (not least
because with MapMessage there's no way to get the number of elements so
you need to guess the size of the list if you want to actually return a
real java.util.List (plus you need to copy). In general it's all just a
bit Eeewww!
So to be honest I'd say either the JMS binding to amqp/list gets sorted
(a good idea anyway) or we should avoid using lists.
Clearly in this case the stuff we want to pass up is semantically a List
but perhaps having a Map body (which makes things consistent with the
bodies of the other request/responses) containing a property called
attributes of type List.
FWIW I personally like the idea of request response bodies all being of
a consistent type e.g. Map this makes it a lot easier to recursively
deserialise into collections/Variants/whatever.
Similarly I'm not convinced by the use of a List in the Query response.
I also think that "The first element in the list serves as a header for
the result set. This provides the list of attribute names that are being
returned for each Manageable Entity. This first element is itself a list
of strings where each element represents an attribute name" feels a
little bit "hacky" to me. I don't really like the idea that the first
element of the list should have semantic significance - surely returning
a Map containing two properties "attributes" and "values" where
attributes is a List of Strings and Values is a List of Lists.
Section 3.4.2.2
Similar comments about the use of List bodies - legal, but a bit of a
pain for Java in particular. In addition this section says "If the
request was unsuccessful then the body of the message MUST consist of an
amqp-value section containing a Map with zero entries" - so this is
saying that if successful a List gets returned but if unsuccessful a Map
is returned - ouch! I'm guessing that this isn't intentional but once
again I point to to my belief that it makes sense to consistently use
Maps as the request/response bodies with whatever else is required being
properties of said Maps. Making this consistent also makes things like
JSON serialisation say to WebApps a degree more straightforward.
Section 3.4.3 and 3.4.4 seem to make more sense both returning Maps but
3.4.5 goes back to returning a List (or a Map of failure).
If I'm honest when I look through these sections the way the bodies have
been structured looks a bit, well, random to me. It doesn't really give
me huge confidence that the information model has been fully thought
through.
Section 3.4.6.1
Why does "Body" say "No information is carried in the message body
therefore any message body is valid and MUST be ignored." when for 3.4.7
the "Body" section says "The body of the message MUST be empty."? Seems
inconsistent to me.
On 17/02/14 14:59, Rob Godfrey wrote:
Working Draft 6 has been uploaded, which addresses the point that the spec
as previously written wasn't actually in compliance with the core AMQP
standard as Fraser pointed out.
https://www.oasis-open.org/committees/document.php?document_id=52237&wg_abbrev=amqp
-- Rob
