|Version 1 (modified by 10 years ago) (diff),|
There exists a pattern in Twisted plugin-using applications where a user interface is presented (typically via a command line tool, but this is not the only possible case) for the selection of a specific plugin from a list of possibilities. Selection is often done by name -- that is, a short, unique string associated with each provider of the desired interface.
The drawbacks of this approach are manifold:
- Implementation of this selection is often duplicated by each user for each plugin interface.
- Each plugin interface is required to supply the name attribute.
- In order for users to make a meaningful selection, some further descriptive information must generally be provided (often in the form of a description attribute which references a string containing prose explaining the features of a particular provider).
- Users must repeat their selection each time they invoke a tool which uses plugins.
- Only objects found by the plugin system can be used, precluding more static configurations where it is desirable for a specific or otherwise well-known object to be used in place of any existing plugin.
Invert the APIs, so that instead of application-level code searching for objects and providing an interface to allow the user to select one, library code implements the selection process and passes one (or more, if multi-selection is allowed) in to the application code.
Details for features of the library code should be filled in here.