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
signature.asc
Description: This is a digitally signed message part