Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.214.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52EFF3B2.2020909@blueyonder.co.uk>
References: <52EEB7A8.3040707@blueyonder.co.uk>
	<52EFB7EA.7040509@redhat.com>
	<52EFF3B2.2020909@blueyonder.co.uk>
Date: Mon, 3 Feb 2014 23:20:35 +0000
Message-ID: 
 <CAFitrpROwQ+6d9WKvES9gkPeJwrpRS0Lvw9aD+AgwtaSpqyY9Q@mail.gmail.com>
Subject: Re: A write up of some AMQP 1.0 Experiments
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=047d7bae499a5b5ae704f188c531

--047d7bae499a5b5ae704f188c531
Content-Type: text/plain; charset=ISO-8859-1

So, erm, yeah...gawp...thought about book writing Fraser? ;)

On 3 February 2014 19:53, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:

> On 03/02/14 15:38, Gordon Sim wrote:
>
>>
>> Although AMQP itself does not place any restrictions on application
>> property names, the selector syntax for AMQP 1.0 is that of JMS
>> selectors[7], where as you noted, data-service is not a valid name.  The
>> extension of the selector explicitly states "JMS header names should be
>> translated to amqp.<field_name> where <field_name> is the appropriate AMQP
>> 1.0 field named in the table above,  with the hyphen replaced by an
>> underscore."
>>
>> However we could probably look at ways to (optionally?) make this more
>> lenient. It certainly is also something that should be highlighted more
>> prominently in documentation somehow.
>>
> It would be *really really good* to be able to make this more lenient
> (would quoted field names be a possibility e.g.
> 'data-service'='amqp-delivery')?
>
> I've used hyphened property names quite a lot and not being able to use
> them would be a bit of a show stopper for me due to the integration issues
> (I've got a lot of producers and they certainly couldn't all be changed
> simultaneously) and given the apparent support at the moment for multiple
> headers bindings between amq.match and a given queue I'm a bit stuck if I
> want to migrate.
>
>
> Re: "The extension of the selector explicitly states "JMS header names
> should be translated to amqp.<field_name> where <field_name> is the
> appropriate AMQP 1.0 field named in the table above,  with the hyphen
> replaced by an underscore."
>
> True, but that could be interpreted to mean the *standard* JMS header
> names, and being slightly flippant it also says "The "properties" of the
> JMS message are equivalent to the AMQP application-properties section" -
> which simply says string.
>

Probably a case of different people reading things different ways, coupled
with slightly ambiguous wording. My reading of that is that its saying
anything that is a 'JMS Property' could be an 'AMQP application-properties'
section entry, which doesnt (and cant) necessarily make the reverse true,
but I agree the wording could have been clearer. The main thing to note
though is that this particular filter was added in a section explicitly
about JMS support, and as JMS properties aren't allowed "-" in their names
this filter couldn't really say they can. What might be an option is making
the filter more general than just supporting JMS semantics, or even
defining another.

JMS <-> AMQP mapping of property names (and values) is an interesting and
annoying subject, and one that we have yet to fully cover in the JMS
Mapping being worked on in the OASIS AMQP Bindings & Mapping TC.

--047d7bae499a5b5ae704f188c531--