Any plugin system will generally have a number of goals:

EPlugin manages to fulfill these goals in most cases. EPlugin isn't a single object or interface in itself, although there is an object titled EPlugin, it is a synergistic ^[1] collection of integrated and continually evolving objects which work together to achieve these goals (and that will definitly be the end of the MarketSpeak). It consists of a loader to invoke extension callbacks, hooks to resolve these callbacks, targets to identify context, and managers which are used by the core code to provide functionality and merging points for the extensions.

EPlugin's design was inspired and influenced by the Eclipse project. It aims at a lower target however, so it was able more easily implemented in a practical time-frame.

EPlugin was chosen as an approach to the problem of adding scriptability to Evolution. Instead of just linking to Perl, or Python, or even Mono by itself an approach was taken which focuses on the application end of the system. So instead of making every part of the application export its functionality and have to deal with whatever script engine is present, EPlugin addresses the hooking part of the equation in a language-independent manner. It also attemps to do it in a way which doesn't impact on the application development either.

The EPlugin world is awash with its own language. The next few sections will introduce the basic plugin nomenclature and high-level view of this world.