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, 28 Feb 2014 16:05:15 GMT
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 :-)
>

I meant language about the form of bodies in *error* repsonses.


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