sylvain-hh / rabbitmq-open-exchange Goto Github PK

During binding creation :

• binding order set via x-order in ranges between 1 to 99 and 1M and more (included values) are reserved to the "super user" only; binding must be denied otherwise
• non "super user" declaring any "x-goto" operator going in those ranges is denied
• default order (x-order not specified) is 10K

On message routing :

• operator "x-stop" differs depending on the current binding order : if in reserved ranges then it should really stops, else it must goto at 1M

The "super user" is not yet defined; it must be implemented.

A binding MUST know if a specific destination (queue or exchange) is already registered at a certain point : those new operators will start by "x-?de(!|)(q|e)".

It must be implemented so that it can replace AE exchange's argument (to avoid equivalence constraint during declare); indeed, this introduce a new "Alternate Queue" feature.

Be able to guard server and consumers against unlikely message content's size or their headers' size.

When upstream filter on sizes will be implemented (#21), we must be able to use those computed values in bindings too. That way, we can set some "absolute thresholds" (channel is closed) while easily use computed values in bindings for pure routing purpose.
Payload content match becomes then possible because there is a way to handle too big messages.

The new binding's type 'set' behaves like 'all' but without message's header keys beeing mandatory.
It MUST BE an error to create a binding with this type without any header's key match.

Useful to manage some "features" between producers and consumers.

Some bindings are simply dumb, here is an example :
x-match all
x-?hkex k1
x-?hkv= k1 v1

All those MUST BE invalidated otherwise the matching algorithm IS wrong.
Another example : goto and stop cannot be declared in a same binding :)

Exact rules have yet to be written.

We should consider binding type "any" like the one in headers exchange : 1 and only 1 match must be true for the binding to be true.
This will reduce complexity in code, and real usecase were is not clear about that one.

This should be always the case at any moment, but we must improve tests :

• maybe rearrange basic_SUITE to be sure to test all operators (and add tests on x-?dt, add exchange dest etc..)
• create bad_binding_SUITE to test all bad binding declaration
• maybe create something like mix_SUITE to do some more mixed tests ?

If producers can do some routing, we must implement some filters to allow or not allow them to add or del some specific destination defined by regex.
Maybe we can consider ops like this one : x-msg-addq -> ^begin.

Replacement of the main queue destination from the routing key value is consuming 1 placeholder binding for very little usefulness. Also, we will find another way to do some regex match from routing key or headers or properties to be used in other operators.
So, there is actually no benefit to use this specific operator, and it must be removed.

Considering the operators "x-add...re...", we should create some new ones starting with "x-add1..." which take only one destination randomly selected among destinations that match the regex.

If we authorize producers to do some routing, there is no reason to distinguish the boolean evaluations of bindings.
So we should end up with 3 authorizations : "OK for specific queue(s)", "OK for queues defined by regex", "OK for specific exchange".

A state is a numeric value identified by a key. Its value can be initially set by a header's key value (numeric of course) or by a match's result. The 4 simple mathematic operations can be applied to a state. Finally, a state can be used as a match result as a numeric value (<, <=, =, !=, >=, >). A state is ready to be used during the parsing of all bindings.
Regarding the current's order binding it is defined in, it MUST BE added 0.3 if it is set only, added 0.6 if set and used in match, and added 0.9 if used in match only.

Operators such as "x-(add|del)(q|e)" do add or del destinations with no guarantee that they currently exist. Some new operator must be implemented to drop destinations that does not exist; this way, it will be possible to know if some dest really exists or not (see #13).

The new operator could be "x-clean-dests".

In add_binding and get_routes functions, Dest is currently the main destination defined in the binding.
This must be modified such as it becomes the array of all destinations to add on match's result "true" (which actually main destination is one of) during the bindings parsing.

Thus, in add_binding function it must be initialized with an empty array when main destination is deleted or when message's RK will replace main destination; by the way, this will prevent the current "x-delq-ontrue" operator to be applied. Also, it should contains array values from x-add[q|e]-ontrue args.
Implies other modifications as it actually replaces the "DAT" variable.

The new binding's type 'eq' behaves like 'all' but must also checks that all message's header keys are present in bindings.
It should be an error to declare such binding's type with "x-?hk!ex" operator.