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 Re: A write up of some AMQP 1.0 Experiments
Date Tue, 04 Feb 2014 20:25:39 GMT
On 03/02/14 23:20, Robbie Gemmell wrote:
> So, erm, yeah...gawp...thought about book writing Fraser? ;)
Yeah it turned out to be longer than I was expecting, it wasn't until I 
saw it printed off that I realised how much there was of it, I was 
clearly having *way* too much fun :->

I do hope that people will find it long and useful/interesting and not 
just long and boring.

TBH I've been incredibly frustrated by the lack of concrete examples for 
a lot of the more interesting use cases and I found myself working 
things out from looking at the code, which isn't a brilliant way of 
making progress from a "user" perspective, so I figured I might as well 
write out my journey - I know I'll find it useful to go back to and 
hopefully others will too.

I don't know about a book, but it's probably worth putting it into 
something prettier than flat text once I get my head around the replies 
you guys have been sending.

>
> On 3 February 2014 19:53, Fraser Adams <fraser.adams@blueyonder.co.uk>wrote:
>
>> 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.
Yeah I realise that, I was just making a few slightly flippant comments 
around semantics. I was going to add that JMS makes a distinction 
between headers and properties and the filter comment was "specific" 
mentioning header names when it came to replacing hyphens with 
underscores and it was specific saying properties later in "AMQP 
application-properties ". It's all a little moot and I was just playing 
games around a very literal interpretation - mainly to get my point 
across that I'd really like support for hyphens --- please ..... :-)

>   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.
I think that I'd prefer making the filter more general if possible (with 
some additional documentation) defining another seems overkill. 
Ultimately knowing what I know now about the hyphen issue in JMS 
property names I'd probably consider migrating to underscores, but 
having a large complex mission critical system with many producers 
deployed quite widely I can't just "big bang" change all my producer 
properties to use underscores. If I wanted to migrate I'd probably have 
to have a period where my consumers initially accepted 
('data-service'='amqp-delivery' OR data_service='amqp-delivery') 
eventually deprecating the former once all producers had migrated.

I'm not trying to be awkward with all of this stuff, but with a mission 
critical system I've got quite a few things that I need to watch out for 
- and as I said to Gordon at the moment neither the current headers 
filter nor selectors will actually work for me because both have quirks 
- selectors not supporting hyphens and legacy headers filter only 
supporting a single binding currently.

>
> 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.
>
Best of luck with that, I can imagine it's a whole world of fun - though 
as you saw from my OCD comments above I've been known to have some fun 
being pedantic with standards :-D

Cheers, and thanks for the comments (and taking the time to read my essay)
Frase


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message