You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to permit the exclusion of a sink based on an incoming request's scope which could be defined by vendor, namespace, and version used in schema configuration. The current implementation will attempt to forward payload from requests to all configured sinks with deliveryRequired enabled. I propose a modification that would permit a list of exclusions for the sink.
Configuration in the config.yml for a sink would become something along the lines of:
An inclusion approach might also be appropriate. If include is not defined then make the sink applicable to all inputs (so as not to break current implementations), but if defined then only apply to specified filter.
The text was updated successfully, but these errors were encountered:
@ricky-galvao what do you think about using https://github.com/timbray/quamina for pattern matching? It's built to handle massive volume, from Tim Bray (the guy who implemented EventBridge pattern matching at AWS).
It would be useful to permit the exclusion of a sink based on an incoming request's scope which could be defined by vendor, namespace, and version used in schema configuration. The current implementation will attempt to forward payload from requests to all configured sinks with deliveryRequired enabled. I propose a modification that would permit a list of exclusions for the sink.
Configuration in the config.yml for a sink would become something along the lines of:
An inclusion approach might also be appropriate. If include is not defined then make the sink applicable to all inputs (so as not to break current implementations), but if defined then only apply to specified filter.
The text was updated successfully, but these errors were encountered: