Latest revision as of 10:46, 5 October 2009

Version 1

This is the format of an XML plugin description for PluS prototype 1 & 2.

DTD

<!ELEMENT plugin (library, entrypoint, prerequisites?, extensions?, extensionpoints?)>
<!ATTLIST plugin ID CDATA #REQUIRED
				vendor CDATA #IMPLIED>

<!ELEMENT library (#PCDATA)>
<!ELEMENT entrypoint (#PCDATA)>
<!ELEMENT prerequisites (prerequisite*)>
<!ELEMENT prerequisite (#PCDATA)>
<!ELEMENT extensions (extension*)>
<!ELEMENT extension (extensionpoint, extender)>
<!ATTLIST extension hostID CDATA #REQUIRED>
<!ELEMENT extensionpoints (extensionpoint*)>
<!ELEMENT extensionpoint (#PCDATA)>
<!ATTLIST extensionpoint ID CDATA #IMPLIED>
<!ELEMENT extender (#PCDATA)>

Textual Description of Elements

plugin

The root element of a plugin description

ID

The ID of this plugin

vendor

The creator of the plugin

library

The jar file containing the classes for this plugin

entrypoint

The entry point of the plugin, the class which needs to be instantiated to run the plugin

prerequisites

Dependencies. Other plugins which this plugin relies on

extensions

A list of extensions this plugin provides

extension

An extension to an existing plugin which this plugin provides

hostID

The ID of the plugin which this is extending

extensionpoint

The class from which a plugin may be extended, or the class (or ID of extension point) which is being extended

ID

An ID for this extension point

extender

The class which is extending an extension point

Further Notes

Minimally, the plugin ID, library, and entry point are required.

ID is a unique identifier for this plugin. For the purposes of the design study, this is not an issue. In practice, a system will need to be set in place to deal with conflicts of namespace, or regulation of namespace.

Prerequisites are the dependencies a plugin relies on. In time, that will probably switch to just calling them dependencies.

Plugins can extend other plugins through the extension points, and extensions which attach at those points. Extension points will need to implement an ExtensionPoint interface. PluS itself doesn't need to deal with exactly how extension occurs. It can simply call the addExtension() method of the extension point. All compatibility checking can be done by the individual extension point. Guidelines will be put in place, so the system is standardised.

Extension points can optionally be given an ID. This must be unique within the extension points of the particular plugin. The default ID is to use the fully qualified class name of the extension point. Either name can be used to register extensions to this point.

Version 2

This version is used for the 3rd iteration of the PluS design

DTD

<!ELEMENT component (library, plugin, extensionpoints?, dependencies?)>
<!ATTLIST component ID CDATA #REQUIRED>

<!ELEMENT library (#PCDATA)>

<!ELEMENT plugin (hostID, extensionpointID, extension)>
<!ELEMENT hostID (#PCDATA)>
<!ELEMENT extensionpointID (#PCDATA)>
<!ELEMENT extension (#PCDATA)>

<!ELEMENT extensionpoints (extensionpoint*)>
<!ELEMENT extensionpoint (#PCDATA)>

<!ELEMENT dependencies (dependency*)>
<!ELEMENT dependency (#PCDATA)>

Notes

As before, the minimal information needed is the ID, library and plugin. However, the plugin description itself has expanded from just the plugin's main class to also requiring the ID of the host component, and of the extension point it connects with. This is due to realising that there is really no difference between an ordinary plugin and an extension, except for the location they plug into.

The (optional) list of extension points is just the IDs of the extension points. It is now left up to the plugin developers to make sure that any extensions they are given are connected in to the right place, given the extension point ID.

Dependencies are also just the ID of the plugin's dependency.