Supporting different filtering algorithms for PUB/SUB
Martin Sustrik
This email is to follow the recent pub/sub discussion, as an argument
for end-to-end subscriptions as proposed here:
http://groups.google.com/group/sp-discuss-group/msg/f68762ff4ce454ab
Treating subscriptions as end-to-end functionality (topology does
broadcast; filtering is done at consumers; filtering at intermediaries
is just an optional optimisation) rather than as hop-by-hop
functionality (mandatory filtering in broker) allows for introducing new
filtering algorithms such as SQL-like queries etc. on the fly.
The reasoning goes like this: In case of mandatory filtering in
intermediaries, introducing new filtering algorithm requires *all* the
intermediaries to be upgraded. This is acceptable in in-house
deployments, however, if we think of ubiquitous distributed messaging
with intermediaries everywhere, including other companies, ISPs, even
backbones, upgrading such infrastructure is almost an impossible task --
as the problems IPv4-to-IPv6 transition clearly demonstrates.
On the other hand, if we opt for end-to-end filtering, introducing new
algorithm requires only the particular consumer endpoints to be
upgraded. Existing intermediaries, with no knowledge of the new
algorithm, can still pass subscription requests upstream and messages
downstream, without doing any filtering. Later on, to improve
efficiency, intermediaries may be upgraded to actually filter the content.
Of course, allowing for different filtering algorithms would raise some
questions, such as "Could we combine two filtering algorithms in a
single topology?" "How are we going to distinguish different
algorithms?" "Do we want IANA to manage algoritm IDs?" Etc. However,
these are no showstoppers AFAICS.
Martin