Version 1 (modified by Jean-Paul Calderone, 11 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.