RE: [amqp] Request to add filters to public registry

["Godfrey, Robert X" <robert.godfrey@jpmorgan.com>]

> I agree with the intent. However I'm not so sure its a good idea 
> (a) to use 'amqp' in 'vendor' extensions and 
> (b) to use 'amqp' unqualified for legacy support for pre 1.0 concepts.

I understand the concern, however these are designed solely to be use as the basis for heritage AMQP mappings.  For a more general exact or pattern matching scheme I would choose a different syntax. I'd happily add "LEGACY_" before AMQP or "V0.X_" to distinguish these as pre-1.0 concepts if people prefer that.

> What about simply: subject-filter-exact, subject-filter-hierarchical and properties-match-filter? 
> They would potentially be applicable even in implementations that were not based on the old pre-1.0 concepts.

These are reasonable names, my main concern with this route is that it points to a somewhat verbose approach to filtering where we would define multiple filter types for each field of the standard message structure (content-type-exact, content-type-filter... etc.).  Clearly a better general purpose solution might be to define an exact match filter type which takes two parameters - the field and the matching value. the only reason to call out these particular filters is because they are those supported by pre-1.0 AMQP systems.

Also, Andreas rightly pointed out that the class should be "restricted" and not composite on the first example.

-- Rob


-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com] 
Sent: Wednesday, April 11, 2012 4:20 PM
To: Godfrey, Robert X
Cc: amqp@lists.oasis-open.org; amqp-ms@lists.oasis-open.org
Subject: Re: [amqp] Request to add filters to public registry

On 04/11/2012 04:00 PM, Godfrey, Robert X wrote:
> I would like to propose add the following three filter types to the 
> registries, along with an associated connection capability
>
>
> 	<type class="composite" name="amqp-direct-filter" source="string" provides="filter">
> 		<descriptor name="apache.org:amqp-direct-filter:string" code="0x0000468C:0x00000000"/>
> 	</type>
> 	<type class="restricted" name="amqp-topic-filter" source="string" provides="filter">
> 		<descriptor name="apache.org:amqp-topic-filter:string" code="0x0000468C:0x00000001"/>
> 	</type>
> 	<type class="restricted" name="amqp-headers-filter" source="map" provides="filter">
> 		<descriptor name="apache.org:amqp-headers-filter:map" code="0x0000468C:0x00000002"/>
> 	</type>
>
> The amqp-direct-filter string is used as an exact character match on the "subject" field of the properties section of a message.
> The amqp-topic-filter string is used as a pattern match against the 
> "subject" field using the syntax defined in AMQP v0-8, v0-9, v0-9-1 
> and v0-10 The amqp-headers-filter contains a map which matches against 
> the application-properties map in the manner defined for arguments in 
> binding to a headers exchange in AMQP v0-8, v0-9, v0-9-1 and v0-10
>
> I would propose a connection capability of
>
> APACHE.ORG:AMQP_EXCHANGE_BINDING_FILTERS
>
> to denote the support of these filter types.
>
> Obviously the intent here is to support legacy v0-x AMQP binding models behind an AMQP 1.0 front end where the consumer creates a receiving link from a node which represents an "exchange" in a legacy AMQP v0-x broker.

I agree with the intent. However I'm not so sure its a good idea (a) to use 'amqp' in 'vendor' extensions and (b) to use 'amqp' unqualified for legacy support for pre 1.0 concepts.

What about simply: subject-filter-exact, subject-filter-hierarchical and properties-match-filter? They would potentially be applicable even in implementations that were not based on the old pre-1.0 concepts.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.