---------- Forwarded message
----------
From:
Fraser Adams <fraser.adams@blueyonder.co.uk>
Date: 28 February 2014 16:43
Subject: OASIS AMQP Management specification wd06 comments
To:
users@qpid.apache.org
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