-
Notifications
You must be signed in to change notification settings - Fork 5
Plugger Base
The Plugger Base was developed so that we could extract and expose components within the Virsona engine so that they can be used on their own and developed as separate open-source projects.
Individual components are written as plugins (we use a ".vip" extension), which can plug into a variety of applications and interfaces: a windows application that we will make available, a website interface, the Virsona bot itself, or projects being developed by other groups. Plugins can describe user interfaces so that they can also exist as independent tools when combined with a container program. The same services can be supplied by different plugins-- for example, content from WordNet can come from a plugin that uses our cache system, a website query, or the data files.
- We publicly provide the PluggerBase dll, which contains the plugin interface, the plugin environment, the Plugger action-reaction framework, and the fast serialization system.
- Plugins are dll files that use the ".vip" extenion, live in a plugin directory, and contain classes that implement the IPlugin interface (which just specifies an Initialize call and IMessageReciever interface) and PluginDisplayName attribute.
- All plugins have access to the PluginEnvironment, which includes the list of plugins, a tree of configuration variables, named dictionaries of data sources and hook listeners, and a collection of available actions.
- The tree of configuration variables is loaded from an xml or ini file; it can be duplicated and over-written with any command-line or url arguments, and then added to by plugins.
- Plugins may communicate by placing information in the configuration tree, by sending messages (on hook calls, through IMessageReceiver), by providing data sources which others will call, or through Actions.
- Data sources implement IDataSource, and can be anything from database tables to external website queries. Only one data source may exist for each name (although it may call or contain other data sources).
Actions are objects that define the IAction interface, which specifies a interface (input and output IArgumentTypes) and a Call function.
Actions are part of an explicit continuation, time-aware, ambiguous and delayed evaluation framework. This framework consists of the following interfaces and classes:
- ICallable : A callable method. The arguments of the call are a value object, a success continuation, and a failure continuation. After the method does its processing, it should call either the success or failure continuation with the result, and return the approximate time it took, in microseconds.
- IContinuation : A success continuation. The Continue function takes a result object, and a failure continuation, which undoes any state changes that might interfere with additional evaluation attempts.
- IFailure : A failure continuation. The Fail function takes a reason, as a string, and a success continuation to "skip over" the faulty call.
- IArena and IEvaluable : An arena is a salience-based evaluation manager, containing IEvaluables, which expose an argument-less method Evaluate. When available, all calls to callables and continuations should go through the arena, where they may be delayed and stored as IEvaluables.
- IAgent and AgentBase : An agent is something that is explicitly aware of its arena. AgentBase is a simple IAgent implementation which always provides a valid arena. Often, classes that implement an ICallable, IContinuation, or IFailure interface will derive from AgentBase, and then always make their calls through the agent contained within.
- Wrappers and Actionlets : Delegates that do the work of an ICallable, IContinuation, IFailure, and IEvaluable are defined (Calllet, Continuelet, Faillet, and Evaluatelet respectively) to ease the code necessary to create these elements; they can be used by wrapping the function in the appropriate Wrapper-- CallableWrapper, ContinueWrapper, FailureWrapper, and EvaluableWrapper respectively.
- Conversion Classes : The following classes allow the work of one element to be done within another: CallableAsContinuation, CallableAsEvaluable, ContinuationAsEvaluable, FailureAsEvaluable.
To ensure that the right action is used, consider defining actions with result types of type NamedArgumentType, and specify a name by which that action (and others like it that take different arguments) will be known.
Again to ease the burden of coding, the following base classes are defined:
- UnitaryHandler : Defines an abstract method
object Handle(object value), and takes the argument information in its base constructor. - ArgumentsHandler : Defines an abstract method
ArgumentTree Handle(ArgumentTree value), and takes the argument information in its base constructor. - HandlerWrapper : Wraps a method group and tries to determine the argument and result types from the method group definition.
- UnitaryHandler : Defines an abstract method
Plugins and each action provided by one may expose a variety of interfaces, for expressing itself in an HTML environment, an XML interface, a Windows environment, or from the command-line. In addition, actions are required to describe their API in terms of ArgumentTypes, which themselves expose interfaces.
The IArgumentType interface defines a name, which uniquely identifies the arguments involved; an example of such an argument; and an ArgumentTree IsValid(ArgumentTree value) function. The IsValid function returns null if the argument is valid, and otherwise encapsulates potentially a tree of validation errors in the resuling ArgumentTree.
The following IArgumentTypes are defined:
- AnyArgumentType : anything possible
- NullArgumentType : only null possible
- UnknownArgumentType : exceptions thrown when argument methods are used
- AmbiguousArgumentType : any of several argument types
- ManyConstraintArgumentType : a result that looks like several kinds of arguments
- SelectableArgumentType : any of a collection of values
- RangedArgumentType : a value within a closed range
- TypedArgumentType : a value defined by a class Type
- StringArgumentType : a string, with a definable regular expression validator and example
- EnumerableArgumentType : an enumeration of values of a type
- DictionaryArgumentType : a dictionary of a specified key and value type
- SeveralArgumentType : an array of objects, each of a particular type
- NamedArgumentType : a wrapper on another argument type that gives a specified name
- SetStringDictionaryArgumentType : a named collection of values, where particular keys map to particular value types; good for HTML interfaces
- AnyStringDictionaryArgumentType : a named collection of values, where any key may be used and any value provided for each; good for HTML interfaces
- LabelledArgumentType : a wrapper on an argument type that provides a label when expressed
- ArgumentTree : A hierarchy of named data, used to store the live configuration and to describe the APIs for actions.
- IMessageReceiver : Interface for receiving messages (e.g. from listening on hooks or other inter-plugin communication).
- IDataSource : Interface for data sources, which can have particularly pieces of information called for, and be wrapped in caches.
- IPlugin and PluginDisplayNameAttribute : The required interface and attribute for implementing a plugin. Also see PluginNotValidException.
- PluginEnvironment : A location for stored state common to all plugins and for inter-plugin communication.
more on action-reaction framework, built-in unit testing