Initial implementation of JMS like selectors for C++ messaging client and broker

[Andrew Stitcher <as...@redhat.com>]

Today I checked in an initial cut of JMS like selectors for the c++
messaging client and broker.

For many more details and the work left to go please see QPID-4558 [1] 
and its linked issues.

If you have comments or find more problems with the current
implementation etc. that might be the best place to discuss.

If you want to try the selectors out here are some brief notes:

1. Although the selectors will work with both 0-10 and 1-0 the 1-0
support currently can't extract properties from messages so will not be
functional enough for many uses. 0-10 support is fairly complete though
and certainly good enough to try out.

2. There are many missing pieces see [1] for details.

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\"}}"

Please give this a try during the 0.22 alpha period and report any
problems you find so we can fix them for the 0.22 release.

I will carry on working on this over the beta period and hope to have
narrowed the missing pieces a lot by the 0.22.

Thanks

Andrew

[1] https://issues.apache.org/jira/browse/QPID-4558


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

Re: Initial implementation of JMS like selectors for C++ messaging client and broker

[Gordon Sim <gs...@redhat.com>]

On 03/19/2013 02:09 PM, Andrew Stitcher wrote:
> The selectors work has now progressed quite nicely and now implements
> the entire selectors language (barring bugs of course). (Some of the
> predefined identifiers are still missing though).
>
> As this is the case I'm now thinking of casting this as not experimental
> in the C++ messaging client API bindings.
>
> So I'm going to change the actual filter used for amqp 1.0 to be the
> registered extension code or symbol (apache.org:selector-filter:string).
> However I think this makes a poor name for a convenience syntax! so I
> propose just "selector" as in:
>
> "queue; {link:{selector:\"color='blue' and price>100\"}}"

I can live with that.

> [possibly "jms-selector" or "apache-selector" might be better as they
> qualify the type of selector in case we end up with more than on in the
> qpid API and implementation]

I prefer the shorter, unqualified version with something more generic 
used if there is a need for any more precision or specificity.

> NOTE: This is not intended to cover all possible amqp 1.0 filter specs
> it is just a common convenience syntax to use selectors for both 0-10
> and 1.0.


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

Re: Initial implementation of JMS like selectors for C++ messaging client and broker

[Andrew Stitcher <as...@redhat.com>]

On Mon, 2013-03-11 at 19:29 +0000, Gordon Sim wrote:
> 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).

The selectors work has now progressed quite nicely and now implements
the entire selectors language (barring bugs of course). (Some of the
predefined identifiers are still missing though).

As this is the case I'm now thinking of casting this as not experimental
in the C++ messaging client API bindings.

So I'm going to change the actual filter used for amqp 1.0 to be the
registered extension code or symbol (apache.org:selector-filter:string).
However I think this makes a poor name for a convenience syntax! so I
propose just "selector" as in:

"queue; {link:{selector:\"color='blue' and price>100\"}}"

[possibly "jms-selector" or "apache-selector" might be better as they
qualify the type of selector in case we end up with more than on in the
qpid API and implementation]

NOTE: This is not intended to cover all possible amqp 1.0 filter specs
it is just a common convenience syntax to use selectors for both 0-10
and 1.0.

On the wire for 0-10 I think I will change the property to be called
"x-apache-selector" but that won't be visible to the user.

An important point here is that there almost certainly also needs to be
some new API in the messaging client API which allows you to add a
selector to a subscription without having to do annoying things to the
string of an address. Any suggestions here would be useful.

> ...
> 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.
> 

I have absolutely no objection to a syntax of this sort to specify a
general 1.0 filter. I am not planning to do this is in the shortst term
however and it is definitely orthogonal to a short form syntax for
selectors.

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

Any more thoughts, strong objections etc?

Andrew


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

Re: Initial implementation of JMS like selectors for C++ messaging client and broker

[Gordon Sim <gs...@redhat.com>]

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

Re: Initial implementation of JMS like selectors for C++ messaging client and broker

[Andrew Stitcher <as...@redhat.com>]

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.

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. 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
\"}...

Andrew

[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

Re: Initial implementation of JMS like selectors for C++ messaging client and broker

[Gordon Sim <gs...@redhat.com>]

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?

I could understand that being used in an argument name to the 0-10 
arguments map on message.subscribe (since it is a qpid specific 0-10 
extension). For an explicit link level property however it seems odd and 
unnecessary (since the entire address syntax is qpid specific).

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.



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