Re: cvs commit: squid3 configure.in

On lör, 2007-09-08 at 08:53 +0800, Adrian Chadd wrote:

> Don't suppose I could take a peek at how you did it? I'd like to write a few
> things up as loadable modules - the logging stuff would be a place to start,
> but I'd like to expose the whole storage API as a clean interface (even given
> mostly the current semantics) to allow entirely different storage modules
> to be selected at runtime.

There is two steps you need to do in order to prepare for loadable
module:

a) Define the APIs the module may be used. Same as for any other code
linked into Squid.

b) Have a runtime registry where the module can register. Such registry
allows for a simple dlopen reference to call a function in the loaded
module which then registers with the main code. This is already in place
for a number of component types in Squid, even if not yet used for
runtime loading of modules (just runtime registering of modules, the
part taking place after the shared object has been brought into memory
by dlopen).

In C++ this is implemented using virtual base classes defining the API
for calling the module allowing it to register and get instanciated when
needed, and just standard C++ for the API the module may call into the
rest of the code..

The ESI code is an example where this has been done, and where the ESI
parsers easily could be turned into loadable modules. The module simply
calls RegisterESIParser("name", moduleobject); at load time to register
itself (currently when the binary loads, but may be just as well from a
dynamic loaded module). There is not a single reference from the main
code to the individual parsers.

This is rightfyllt ignoring the Windows DLL export issue, which is just
a platform oddity and not hard to get around should one want to.

So in the end getting Squid ready for dynamically loaded modules means

a) Getting the APIs the modules needs to use to perform their actions
reasonably in shape.

b) Adding suitable component registries, allowing modules to register at
runtime and avoiding direct knowledge of the implementation in other
parts of the code.

'a' is quite important if we are to open for third-party modules as
there is then a need for a reasonably stable API the modules can use.
It's not going to be seen well if key aspects of those APIs changes
every month..

but for the goal of spliting Squid in loadable objects all under our
control then it's not so important and just 'b' suffices to get it done.

Regards
Henrik