qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: OASIS AMQP Management specification wd06 comments
Date Fri, 07 Mar 2014 11:57:06 GMT
Working Draft 8 has just been uploaded:

https://www.oasis-open.org/committees/document.php?document_id=52425&wg_abbrev=amqp

I think this addresses your comments about the return value from Query, as
well as locales still being lists...

This'll probably be the last update for a couple of weeks as I'm going to
be travelling as is the other main editor of the document.  I'll update the
Java Broker to be compliant with this draft before Monday I hope.

-- Rob


On 28 February 2014 17:04, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

> Hi Fraser,
>
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
>
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
>
> As to lists in the bodies... The JMS Mapping that Robbie is working on
> will define exactly how these get passed back.  Given the nature of the
> data an ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
>
> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list
of
> lists> }, or having attributes be a comma separated String in the
> application-properties.
>
> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
>
> BTW WD07 can be downloaded here:
>
>
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
>
> -- Rob
>
>
> On 28 February 2014 16:43, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>
>

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