Transport-Level Filtering¶

Introduction¶

For efficiency, it is desirable to filter events at the transport-level, i.e. during processing in connectors (see EventProcessing for an overview). The decision whether a notification (or later event) can be discarded or not should be made as early as possible. In general, during processing in connectors, there are at least two opportunities:

1. After obtaining notifications from the wire, but before decoding the complete meta-data and payload
2. After decoding meta-data and payload, but before constructing an event object and adding additional meta-data

Notification Filtering (1)¶

One possible method for filtering notifications before decoding everything works by extracting on the required meta-data fields. This has to be supported by the serialization mechanism used for notifications.

An implementation of this scheme could work by implementing backends for XPath engines that operate on serialized data instead of DOM-infosets. The connector in question could then translate client-supplied filters on event meta-data into XPath expression that would be applicable to supported serialization formats.

Example:
A Spread connector with suitable serialization mechanism for notifications (e.g. Protocol Buffers) could translate an OriginFilter for origin A60CBE00-99B8-11E0-8A00-001AA0342D7D into

Notification/meta_data[@sender_id="A60CBE00-99B8-11E0-8A00-001AA0342D7D"]

The matching could be implemented efficiently by an XPath backend that skips over fields of the serialized representation which do not have to be inspected to decide whether the XPath matches.

Payload Filtering (2)¶

TDB