Plugin-based applications (by alaric)
Another issue in plugin system design is how to handle plugins of more than one type. For example, a session tracking plugin in a Web application would need to:
- Be a part of the handler chain for all incoming HTTP requests, so that it can decode session cookies and set up the session for other plugins to access, and it can also handle login form POST requests.
- Be a part of the handler chain for HTTP header generation, so that it can issue cookies to set up new sessions
- Provide a new set of options for the script interpreter, giving it extra commands to set session variables and to add bought items to a shopping cart
- Provide an extra set of pages to show the contents of the shopping cart (by registering as a class that the user of the application can instantiate at a URL such as "/cart/")
That involves taking part in two different handler chains, adding several items to a set of options, and registering a new web application class. Ideally, this should all be in one single installable plugin, rather than needing to be three separate plugins. So perhaps make your plugin registry work by having a single list of plugins (and their load parameters), load them in turn, and then let them add themselves to chains and option sets as required, or try and register themselves as the one and only user database plugin (which will then fail at load time if there is already one loaded). However, you then need a mechanism for the user to specify the order in which order-dependent handler chain plugins should run, rather than just "the order they are listed in the configuration file", since two plugins may need to run in one order on one chain but in the opposite order on another chain. Perhaps the best way of handling this is, for such order-dependent chains, to have a separate part of the plugin registry configuration for each chain listing the order the different plugins should run on that chain, with a configuration validity check to make sure that all plugins that register for that chain are listed, and there are no plugins in the list that do NOT register for that chain.
Oh, just to confuse things, one plugin might potentially register on the same chain twice, in order to be involved at two different stages. Perhaps a privacy plugin might encrypt certain parts of the invocation parameters before a series of untrusted plugins are let loose upon them, then decrypts them afterwards.
Also, sometimes a plugin will want to use a third-party component. And sometimes another plugin will also want to use it. Perhaps this can be handled by using the underlying platform's native conventions for using shared copies of third-party components, or perhaps those are insufficient and confusing, in which case it may be necessary to add a list-of-options plugin type to the registry purely for 'shared components'; the core system never requests modules of this type, and they have no standard interface, but modules that need to use a shareable component can then request it by name from the shared components plugin registry, and then use its published interface. That allows the user to manage both plugins, and the shared components they require, from a single administrative interface, which may be better than messing with DLL Hell. Or Shared Library Hell. Or PHP Include Path Hell. Or any other such hell.
Fri 15th Sep 2006 2:13 pm 
Subscribe