Dispatching operations to user-defined methods

[Hallvard B Furuseth]

I'm wondering how to design this:

An API to let a request/response LDAP server be configured so a
user-defined Python module can handle and/or modify some or all
incoming operations, and later the outgoing responses (which are
generated by the server).  Operations have some common elements,
and some which are distinct to the operation type (search, modify,
compare, etc).  So do responses.

There are also some "operations" used internally by the server -
like checking if the current session has access to perform the
operation it requested.

The server will have various internal classes for operations and
data in operations, and methods for the user to access them.

One obvious implementation would be to provide a class Operation,
let the user define a single subclass of this, and have the server
call request_search(), response_search(), request_modify(),
check_access() etc in that subclass.

Then I suppose the server would turn individual operations into
instance of internal subclasses of the user's subclass - class
SearchOperation(<user's class>), ModifyOperation(<user's class>)
etc.  Begins to look a bit messy now.

And I'd like to try several methods - first try if the user defined
response_search_entry() (one type of Search operation response),
then response_search(), then response(), and after that give up.
For that one, the Pythonic approach seems to be to define a class
hierarchy for these, let the user subclass the subclasses and define
request() and response() methods for them, and let Python handle the
search for which request() method to use for which operation.  And
the server must keep track of which subclasses the user defined.
This too feels a bit messy to me.

Also there are plenty of operation parameters the user might wish to
dispatch on, e.g. maybe he can handle Entry but not Referral search
responses.  I imagine it's more efficient to dispatch in a Python C
module than to leave that to the user.  But I may be getting too
ambitious now.

Anyway, ideas?  Am I overlooking something obvious?

-- 
Hallvard