qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Initial implementation of JMS like selectors for C++ messaging client and broker
Date Mon, 11 Mar 2013 19:29:51 GMT
On 03/11/2013 05:34 PM, Andrew Stitcher wrote:
> On Mon, 2013-03-11 at 13:01 +0000, Gordon Sim wrote:
>> On 03/04/2013 11:13 PM, Andrew Stitcher wrote:
>>> 3. Selectors are specified on the as a "qpid.selector" property of links
>>> in the messaging API address syntax: for instance an address might be
>>> like
>>> "queue; {link:{qpid.selector:\"color='blue' and price>100\"}}"
>>
>> Why is the 'qpid.' prefix used here?
>
> It's a placeholder, suggest something more appropriate and I will change
> it.

If the intention is to warn users of something experimental or likely to 
change, I would use 'x-' in line with some of the 0-10 specific options.

> Currently the implementation is incomplete (and qpid specific) and so I
> didn't want to use something in the "amqp" space. When this
> implementation completely implements the "standard" in [1] I'd expect to
> use amqp.selector as the key.

For clarity, that isn't actually an AMQP standard, just a registered 
extension (under the apache domain).

> It is true that I'm trying hard to ensure
> that any selector in the current implementation won't change it's
> meaning when the implementation is finished, but I may screw that up.
>
>> ...
>
>> There may be a need to allow different kinds of filter to be specified
>> also. Having a filter option that could be a nested map (and would thus
>> allow some type annotation to be added if needed) might therefore be a
>> good idea.
>
> I think this starts to get more cumbersome than necessary, I'd say just
> use a different link property name for a different type of
> selector/filter. viz:
> ....link:{amqp.selector:\"bal=foo\", otherfilter:\"another spec here
> \"}...

Ideally there would be a generic way to specify the filter-set used for 
1.0 (less of an issue for 0-10 where arguments to the subscribe can 
already be controlled). I'd like to avoid having to add explicit 
handling into the client for every type of filter supported by whatever 
broker connected if possible.

1.0 certainly doesn't make that easy, but I was thinking of something 
along the lines of e.g. 
...link:{filter:{'apache.org:selector-filter':'bar=foo', 
'otherfilter':'another spec here'}}... i.e. where there is some 
indication of the descriptor to use.

We could of course have some shortcuts/aliases for the common ones. E.g. 
if no domain was specified or,apache could be assumed, allowing 
'selector-filter' as a shorter name. Further, if the filter value was a 
simple string rather than a map then it could be interpreted as meaning 
the 'default' filter type (which for now would be the registered 
selector extension perhaps, but might later be some official standard).

> [1]
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/apache-filters.xml#type-selector-filter


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


Mime
View raw message