Thank you for the help, Robbie.
I had thought of link capabilities and then abandoned that thought without adjusting the headline.
I m on the fence myself about having all and you make good points so I ll drop it.
Not having the constant filters listed is indeed an oversight. We use true/false filters as the simplest filter primitives on some entities. The target scenario is not for source filters,
but some other entity that has filtering capabilities and is updateable via AMQP Management. With false I can easily and efficiently put a cork into a route without tearing down the topology or having to use a SQL 1=0 thing.
I ll do the updates shortly.
Von: Robbie Gemmell <
rgemmell@redhat.com>
Gesendet: Mittwoch, 11. September 2019 03:35
An: Clemens Vasters <
clemensv@microsoft.com>
Cc:
amqp@lists.oasis-open.org Betreff: Re: [amqp] Groups - AMQP Filter Expressions uploaded
The new heading is "2.2 Connection and Link Capabilities", but link capabilities are never mentioned.
There is a reference that seems to be broken, at least in Libre Office: "connection capabilities (see Section 2.7.1 [Error: Reference source not found])." Perhaps meant to be a link to the Open frame definition in core spec?
There is the 'all' capability and then separate capabilities listed for 'grouping', 'properties', and 'sql' filters, but there is no separate capability specified for the 'constants' filters and it doesn't seem that any of the other capabilities (including
'all') would currently cover support of them. I also wonder if these filters are really needed.
I don't think having both an 'all' capability and individual ones actually makes sense in the end, since it seems like both forms would need to be listed as desired and offered most of the time to cover interop with what a given peer decided to use for its
support. Peers aren't allowed to use capability-guarded functionality, even if offered, unless they had indicated it was a desired-capability. As a result, a peer offering only the 'all' capability would not strictly satisfy requirements of a peer that desired
e.g the 'sql' capability. A requesting peer would have to indicate desire for all the individual capabilities it wants and also the 'all' capability (even if it didn't desire all the functionality) to cover itself against what any given offering peer actually
advertised. An offering peer that didn't specifically inspect the desired capabilities before deciding what to offer would similarly have to present the individual and 'all' (a problem if it didn't support all the functionality, the reason both forms of capability
exist) capabilities to cover what any given requesting peer actually indicates as desired for its usage.
Using an 'all' capability also makes it difficult to ever introduce any additional filters and include them in the 'all' set, since it would require bumping the capability version qualifier and the annoyance of doing that, even if all the existing functionality
is unchanged. I think dropping an 'all' capability makes most sense in the end.
Robbie
On Tue, Sep 10, 2019 at 8:43 PM Clemens Vasters <
clemensv@microsoft.com > wrote:
Added four capabilites: One each for groups, property filters and SQL, and one for all . Please review.
Von:
amqp@lists.oasis-open.org <
amqp@lists.oasis-open.org >
Im Auftrag von Clemens Vasters
Gesendet: Dienstag, 10. September 2019 12:42
An:
amqp@lists.oasis-open.org Betreff: [amqp] Groups - AMQP Filter Expressions uploaded
Submitter's message
Added the capabilities section.
-- Mr. Clemens Vasters
Document Name :
AMQP Filter Expressions
No description provided.
Download
Latest Revision
Public
Download Link
Submitter : Mr. Clemens Vasters
Group : OASIS Advanced Message Queuing Protocol (AMQP) TC
Folder : Working Documents
Date submitted : 2019-09-10 12:41:11
Revision : 5