Re: [zi-dev] RFC: Plugins Architecture

Hi,

>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.

Can a customized plugin (e.g. com.zzoss.zic.plugin.filerole.myfilerole) 
extend the way, the file role attribute is handled ? Or does a customized 
file role plugin always replace the complete way the file role attribute is 
handled ?

>* 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>

How does com.example.plugin.filerole look like ? Is this a classic package 
(with package.xml) for the installer like the one from 
com.zzoss.zic.plugin.filerole ?

>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.

Can a plugin have dependencies ? If yes, to what (other plugins or 
packages) ? What if a plugin got a dependency to another plugin/package, 
which throws some config form (= use some other plugins) ?

If we would allow a plugin to have dependencies to other plugins _and_ 
packages, we have to distinguish between the way, those dependencies are 
solved.
a) Packages: If a plugin got a package dependency, the package should be 
installed under some kind of plugin root, since all packages are requested 
by the plugin and not by the application.
b) Plugins: If a plugin got a plugin dependency, the plugin is installed by 
the installer (with version number, since it is possible that different 
packages/plugins use different versions of plugins)

So installing an application means "plugin download => optionally config of 
plugin (plugin uses another plugin) => plugin process" and afterwards 
"packages download => optionally packages config => packages process". If 
these two processes are executed one another (so steps of installer plugins 
+ step of packages), the user would recognize it only as one or two 
additional steps when installing an application.

>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.

This means, that customized plugins by an application are afterwards 
"usable"  by any application since it is stored in the "global installer 
plugin repository" ?

>* 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.

So the installer got one default plugin directory, one cached plugin tgz 
directory (if a application requests a plugin which is already available) 
and one plugin directory per application ?

><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.

can e.g. the filerole plugin access a value entered by the user in the 
config plugin ?
if a plugin will use some routines of another plugin (e.g. filerole asks 
config plugin for a special value of some package config), we might 
introduce some kind of plugin sdk. this contains the basic methods for 
communication between plugin <-> installer and plugin <-> plugin in 
abstract form. maybe porting plugins and the zic itself to different 
platforms is easier by a defined plugin sdk instead of a php-specific 
"global var interface".

>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>

sounds good.
if the installer got a cached version of exact the same plugin (name and 
version) defined in plugins.xml, does it still download the plugin or use 
the cached for installing it to plugin directory of application ?

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

handled before in installing or when requested by packages during 
installation ? are you sure you can combine this with the new zic plugin 
architecture ?

my two cents,
Christian 



-------------------------------------------------------
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