qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject OASIS AMQP Management specification wd06 comments
Date Fri, 28 Feb 2014 15:43:19 GMT
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.

"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.

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 

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

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