Re: [amqp-ms] Re: [amqp] Request to add filters to public registry

[Raphael Cohn <raphael.cohn@stormmq.com>]

So if I expose one node to MQTT and AMQP, say, I'd like to expose it with a restricted filter-set (the links for it can only support filters that match MQTT's primitive globbing). However, the same implementation might expose the same or other nodes over native AMQP, or other protocols, with a wider range of filters possible. And given that nothing prevents an implementation being nothing more than a scale-out proxy to behind the scenes 'things', there's nothing to say one impl == one running broker which has all the features needed within it. Indeed, such facades are quite likely with intelligent global routing...

So connection level properties aren't so useful here. And they certainly don't allow partial implementation of filter kinds, particularly by clients.

Raphael Cohn
Chief Architect, StormMQ

Secretary, OASIS AMQP Standard
raphael.cohn@StormMQ.com
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com

On 11 April 2012 17:55, Andreas Mueller <am@iit.de> wrote:

I don't see that on the link level. A link requires a session requires a connection which is bound to an AMQP impl that supports a specific filter set. 

Am 11.04.2012 um 17:45 schrieb Raphael Cohn <raphael.cohn@stormmq.com>:

Why are these connection capabilities and not link capabilities?

I can easy see having a solution that, for example, bridges STOMP or MQTT; consequently, the supported filter kinds on one link would differ, and clients could easily connect to such a broker without having to support the full gamut.

Raphael Cohn
Chief Architect, StormMQ

Secretary, OASIS AMQP Standard
raphael.cohn@StormMQ.com
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com

On 11 April 2012 16:19, Gordon Sim <gsim@redhat.com> wrote:

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: amqp-ms-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: amqp-ms-help@lists.oasis-open.org

---

IIT Software GmbH
Fahrenheitstr. 1, D28359 Bremen, Germany
Tel: +49 421 2208-166, Fax: +49 421 2208-167
Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller
Steuernummer: 71/572/04100, VAT: DE199945912