Plugin-based applications (by alaric)

There are a few different general structures of plugin registry I've seen, and probably a few more I've not seen yet. For any given type of plugin (and an application may well have more than one type of plugin, each handled differently), I think the registry can boil down to:

1. There Can Be Only One. For example, most applications only support a single user database. In this case, the module registry really just needs to specify which user database plugin to use, along with any configuration that plugin needs (contact details of an LDAP server, etc)
2. List of options. For example, the rich text to HTML converter or page template language plugins I mentioned above. In those cases, at some other place in the system is (for example) a data record for a page, including a reference to the template used; and the template itself contains the source code for the template, plus the name or ID of the template engine plugin to use to process it. Therefore, the plugin registry needs to have a list of active plugins, each with an internal ID (possibly assigned to the plugin by the registry, or possibly named in the plugin itself) and usually a human-readable name. When somebody creates a template, they can then be given a list of the human-readable names, and the ID of the chosen template engine plugin stored in the template record. Basically, the core of this registry type is that there is some point in the system where something can be handled in one of a number of ways, so the system can just give the user a list of installed available plugins to choose from.
3. Handler chain. In this case, the registry holds a list of activated plugins (each possibly with configuration), but all of the plugins of that type are invoked in turn at the appropriate point in the system. An example of this is a notification plugin; a monitoring system may be called upon to issue notifications of events, which may come out via email, SMS, HTTP POSTs, insertions into a log of events, or whatever. Therefore, the user may select a bunch of notification plugins, and they will all be invoked whenever a notification occurs. One variation on this theme is one where the plugins are invoked in some specified order (the order they are listed in the registry, or in order of a priority field written into the plugin itself), and each plugin gets the option of passing the invocation on to the next plugin in the list, or 'claiming' it itself, which causes processing to stop. Yet another variation on this is where plugins that pass the invocation on may modify the invocation parameters before they are passed to the next in line; Apache modules work like this, which allows them to (when presented with an HTTP request) apply rewriting rules to alter the target of the request, or to return some content or an error and then prevent any further processing, as they have handled the request themselves.
4. Classes. Sometimes plugins are like classes in an object oriented system, and you want to have multiple instances of them. For example, a Web server might have web applications as plugins, and you might well want to run multiple instances of the same application on different URLs, with different configuration (eg, their own database). In this case, the plugin registry must keep a list of active plugins, then a list of plugin instantiations, which specify a plugin to instantiate, its configuration, and some kind of identifier for the instance (eg, the base URL to make it appear under in the Web server).

Pages: 1 2 3 4

No Comments

No comments yet.

RSS feed for comments on this post.

Leave a comment