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 B Furuseth]

I'm wondering how to design this:
(...)
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.
(...)

<Slap head> Or two classes - one operation class and one class
subclassed by the user.

Still need some way to let the user provide both general and more
specialized methods though.

 

[Michele Simionato]

Apparently Guido fell in love with generic functions, so (possibly) in
future Python
versions you will be able to solve dispatching problems in in an
industrial strenght
way. Sometimes however the simplest possible way is enough, and you can
use
something like this :

class SimpleDispatcher(object):
"""A dispatcher is a callable object that looks in a "namespace"
for callable objects and calls them with the signature

``<dispatcher>(<callablename>, <dispatchtag>, <*args>, <**kw>)``

The "namespace" can be a module, a class, a dictionary, or anything
that responds to ``getattr`` or (alternatively) to ``__getitem__``.

Here is an example of usage:
.... return 'Manager'
.... return 'Member'
.... return 'Anonymous'
'Member'
"""
def __init__(self, ns):
self._ns = ns
def __call__(self, funcname, classname, *args, **kw):
try:
func = getattr(self._ns, '%s_%s' % (classname, funcname))
except AttributeError:
func = self._ns['%s_%s' % (class

 

[Hallvard B Furuseth]

Apparently Guido fell in love with generic functions, so
(possibly) in future Python versions you will be able to
solve dispatching problems in in an industrial strenght way.

Looks interesting, I'll keep an eye on that.

Sometimes however the simplest possible way is enough, and you
can use something like this :

class SimpleDispatcher(object):
(...)

That doesn't make use of any subclass hierarchies the user defines
though. But maybe it's just as well to scan his class for names
once he has defined it, and build the dispatch table myself.