[PEAK] Content-based routing via generic functions

Phillip J. Eby pje at telecommunity.com
Thu Jul 22 19:15:48 EDT 2004

This is mostly a note to myself on a future application of generic 
functions...  content-based routing ala Elvin.

Specifically, imagine a messaging server that allows clients to subscribe 
to messages based on a set of criteria, e.g. as specified by a short Python 
expression.  If such a system were based on simply evaluating each 
subscriber's criteria, routing performance (ignoring I/O) degrades linearly 
with the number of subscribers, regardless of message applicability.  But, 
with the generic function engine, all criteria are evaluated at most once 
per message, and routing performance degradation should be sub-linear.

Such a messenging server could use a variety of protocols to receive or 
send messages, including Jabber XML streams, XML-RPC, POP/SMTP, or any of 
the various Python messaging protocols such as PB or Pyro.

In effect, each "subscription" can be treated as a "method" to be added to 
the generic function.  The actual method would probably be a method on an 
event source used to create the subscription, with an events.Task 
monitoring the event source and sending the events over the wire once 
received.  By using a simple method combiner that just invokes all of the 
applicable methods, all the subscriptions that a given message applies to 
can be fired.

Interestingly, this "messaging server" itself doesn't have to have any 
I/O-specificness to it.  It's probably more appropriate to just call it a 
"message router".  This means you could just use it in-process for various 
purposes, or create one and allow multiple simultaneous external protocols 
to use it.  For example, one might have both Jabber and Pyro clients 
sending or receiving messages through the same "router".

Of course, for this to work, there'd have to be a few minor additions to 
the current generic function framework.  Primarily we'd need a way to 
remove methods from a generic function.  Also, a message router that was to 
be used in an event driven system probably wouldn't want to actually fire 
all the subscriber events upon receipt of a message, but would instead 
schedule them to be fired in subsequent iterations of the event loop, in 
order to maximize responsiveness.  But neither of these things is any big deal.

Also, if you were going to use Python expressions as your subscription 
filters, you would need to use something like Zope 3 security proxies to 
avoid arbitrary code execution.  Or, more likely, just use a different 
expression parser to construct the Signature objects, one that's limited to 
the functionality your system wants to offer.

Last, but not least, if there were a way to verify whether a generic 
function has any methods that apply to a given signature, then we could 
also have a "quench" capability similar to that of Elvin.  That is, if you 
have a set of connected message routers, you can avoid inter-router traffic 
for messages that don't meet any criteria at the target router.  For that 
matter, you can also avoid even *generating* messages that nobody cares about.

This seems also like an interesting extension for logging, performance 
measurements, system monitoring, and other enterprise metrics.  That is, 
those systems also potentially have need for such event routing.

More information about the PEAK mailing list