httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Spero" <>
Subject 2.0: Thoughts on the Module API/Middle End
Date Tue, 04 Aug 1998 04:00:41 GMT

I've been meaning to post some thoughts about the design of the module API ,
but I've been sick and busy, so I thought I'd just throws some ideas up for
people to rip to shreds.Sorry if a lot of this is incoherent.  I'd like to
blame it all on voice recognition, but it's really my fault

First of all, some stuff that should be non-controversial.

1.  The current API is too HTTP specific, and too procedural in nature.  It
is ill-defined, and inflexible when it comes to adding extra functions.  It
is very hard to predict how modules from different developers will interact
with each other, or two used to modules providing the same type of service
at the same time (for example, using two different authentication modules to
get user information from two different places).


Back-end vs. middle-end, objects vs. names.

 this may be controversial, I like to think of the things that are managed
by the back end of the server as being objects; these objects may have
state, provided by a filesystem or a database, and can be accessed by
invoking many different methods.  The implementation of these methods could
potentially come from code provided by many different modules; it is the job
of the middle end to work out which methods go with which object. Methods
can be grouped together to form interfaces (like in Java or CORBA).

Use different types of Interfaces.

Each type of activity should be defined by a different interface; it should
be possible to implement several different interfaces in the same module; it
should also be possible to only implement part of an interface, with the
remaining implementations coming from different sources.

Use Late binding.

Interfaces should be flexible and  late bound; module should only provide a
single symbol, which would be a standard function identifying the methods
and interfaces provided by this module. This identification the should be
done using strings instead of locations within structs to avoid problems
caused by adding methods to an interface.

Provide fast method invocation

Method indications should be fast; on the order of a jump to a function
pointer, instead of a linear search.  It should be possible to use this
invocation method to provide basic services to other modules (for example,
then might be a database interface). It should be possible to take modules
which use a carefully limited set of system services, and automatically load
them into the kernel, or access them from a kernel module.

Object VTABLES can be pieced together at run time.

The process of constructing an object might  start with name resolution;
For example, a database based implementation of a meta- information
interface might be bound to /.  A filesystem based implementation of the
name resolution interface could then be bound to /files. Control of  the
name resolution processing would then be passed in to that implementation of
the  name resolution interface, which would do further construction of the
object, including handling tasks like content-negotiation.  This can be
combined with other mechanisms for locating appropriate implementations to
use with this object.

VTABLES should be mostly pre-computed.

 the important thing is that it should be possible to statically evaluate as
much of the resolution process as possible to build cached vtables for the
common-path. This could be done through a method in the name resolution
interface which would return a list of  tuples of name prefixes and
vtables. It should be possible to quickly combine vtables for cases where
dynamic processing is necessary. This might involve links rather than

Method Combination Should Be Predicatable And Controllable.

It should be possible to control how methods are combined.  This might
involve e.g. making a pointer to the next function to call available to the
invokes method, in the style of LISP or Dylan; or trying all methods until
one succeeds, all succeed, etc. .  The main constraint is that it should be
easy to see what sort of method combination is being used without having to
read every single piece of code involved.

Object/VTABLE  Construction Should Be Customisable

The process of name resolution and method combination must be customizable
as an interface; this allows for other types of object, in particular front
end protocol stacks, to be implemented using the same mechanisms.


All access to objects should be  mediated by a cache (the core of the

There should be certain types of stereotyped interfaces e.g. for objects
that behave like files.  This allows caches to be smarter.

Once in object has been resolved, it should have an object ID which can be
used in internal caching.

View raw message