qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [GitHub] qpid-proton pull request #159: PROTON-1940: [c] normalize encoding of multip...
Date Wed, 26 Sep 2018 15:15:31 GMT
On Wed, Sep 26, 2018 at 10:38 AM astitcher <git@git.apache.org> wrote:

>
>     What is 'multiple="true" field'? There is nothing called this in the
> standard is there?


 Alas there is, which is where the problem started. It is *yet another* way
to represent a variable-length sequence of identically typed values but
with new and redundant encoding options! Here are the proper links, I'll
update the code:

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#doc-idp115568
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html#section-composite-type-representation

I'll write this up properly for the next go-round

The ="true' naming seems to indicate boolean fields, but this is not the
> case afaict - and this really applies to a list of things that can also be
> empty in which case we just use null instead of the empty list.
>

Correct - multiple="true" is part of the XML field definition, which is
part of a composite definition, which is how frames and other stuff are
described. A field with multiple="true" is allowed to be any of: null,
empty array, single value, non-empty array. null and empty array MUST be
treated as equivalent, so must single value and array of length one. All
this redundancy means that some popular AMQP implementations (.NET) don't
properly handle the empty-array case. Now technically that is their bug,
but normalizing the encoding is more efficient anyway, and more likely to
interop generally. Even multiple="false" fields are allowed to be null, so
it's unlikely that anybody will choke on a null field.

    Also url to local file system is not very helpful!
>
Doh!

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