[zi-dev] RFC: Plugins Architecture

Hi,

for the next release ZIC-1.1.0, I plan to modify the plugin architecture as 
follows.

* Default and customized plugins

In general, the ZIC brings default plugins with him that other applications 
can use to install their packages. So the new plugin architecture is of 
interest to those who would like to develop their own plugins e.g. to process 
fileroles.

Customized plugins defined in an application.xml, overwrite conditions defined 
by the default plugins. This means that a customized plugin can overwrite the 
way that a file with the role "php" (defined in the package.xml) is 
processed. It can of course also introduce new file roles that it handles.

* Separating plugins from packages

Basically, the new architecture is about separating plugins from packages.

Up to now, plugins are defined within the application.xml element <packages>. 
I would like to define plugins instead in a new <plugins> element:

<plugins>
	<plugin name="com.example.plugin.filerole" rel="ge" version="1.0.0"/>
</plugins>

This way, the installer can clearly detect required plugins and install them 
into its framework before the packages are processed by those plugins. Also, 
the installer can look up if a plugin meeting the dependency requirements 
(rel, version) is already installed.

This approach most notably accounts for the different character of plugins: 
they do not have dependencies to other plugins or packages, they are always 
required and never optional once they are defined, and most importantly: 
plugins are a part of the installer, not of the application. They are just a 
mean to install the application, not to provide the run-time routines of it.

* Installing plugins

In general, customized plugins are handled per application. This means, if two 
applications use the same customized plugin, the installer does install the 
plugin for each application separately. It is only the default plugins that 
ship with the installer that are used for any application without installing 
them again for each installation.

* Distribution of plugins

Application developers can either integrate the customized plugins with the 
application bundle, or provide the download location in the XML descriptor.

The installer will prompt the user for download and installation of the remote 
plugins.

* Plugin-specific install paths

A plugin can define paths that the user needs to specify before installation 
of the application. For example, PEAR stores the files defined in package.xml 
with the role "test" or "data" in a directory different from the "php" files 
installed to the include path directory. ZZ/OSS Installer can with 
plugin-specific paths mimic this behaviour in a flexible way by having each 
plugin define the paths it requires to work properly.

Technically, those paths are defined in an input.xml just as they are for the 
config plugin, e.g.:

<input>
    <widget
	name="path"
	label="A plugin-specific path"
        variable="my_path"
        info="Just a sample."/>
</input>

The respective paths can be specified during the installation process by the 
user in the same mask where he defines the application baseinstalldir path 
(application_settings.php). This means that the installer has to (maybe 
download and) unpack every plugin and read the input.xml descriptor of each 
plugin specified in the application.xml in the application_settings.php file. 

Those paths are stored in a global variable, e.g.

$GLOBALS['ZI']['plugins']['com.example.plugin.filerole']['my_path']

which is accessible by the plugin routines.

* Plugins manager

The installer will provide a GUI similar to the package manager, where users 
can manage plugins, installing, upgrading, removing them, and also read the 
package.xml information of the plugin. If a plugin has been removed althoug 
an application that is already installed and supposed to be upgraded, needs 
this plugin, then the installer will download and install it again. Otherwise 
the application upgrade can only be aborted.

* Plugins XML descriptor

As a consequence of optionally downloadable customized plugins, there needs to 
be a plugins.xml for downloadable plugins just like the packages.xml for 
downloadable packages. Thus, we have four XML descriptors for repositories: 
distributions.xml, applications.xml, packages.xml, plugins.xml.

For the installer to be able to find the plugins.xml, it needs to be defined 
in the applications.xml, just like the packages.xml, except for the role 
"plugins":

<descriptor role="plugins">http://www.example.com/plugins.xml</descriptor>

* Downward compatibility

Of course, the new installer will also be able to deal with the way that 
plugins have been handled before.


Always happy about feedback,
Sandro



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn