Re: [FR-devel] FreeRIDE startup

[Horacio Lopez]

----- Original Message -----
From: "Laurent Julliard" <address@hidden>
To: <address@hidden>
Sent: Sunday, January 27, 2002 10:07 AM
Subject: Re: [FR-devel] FreeRIDE startup
[massive snip]
> As a matter of fact I was exactly thinking about the same thing this
> morning. I had not used the plugin stuff yet but I was making an analogy
> between our plugins and the way the Linux kernel handles modules. And I
> do think link you that it would be great to have a Linux-like approach
> to the plugins loading
>
> Linux has a simple but yet very useful languages used in
> /etc/modules.conf. Things like
>
> - alias: define an alias name for a plugin
> - pre-install: automatically load a (list of) plugins before yours
> - post-install: same after yours is installed
> - pre-remove: remove other plugins before yours in is removed
> - post-remove : same except plugins are removed after yours has been
removed
>
> This is not exactly the same approach as yours in the sense that here
> the plugin would play an active role in triggering the event that is
> going to pre-install the required plugins. If the necessary plugin is
> already laoded then the pre-install would have no effect of course.
>
> Another effect of pre-install is that it could also act as a dependency
> checking. If the required plugins are not there then you could throw an
> exception and say that you absolutely need them
[massive snip]

Other two advantages on this idea:

* You could have problems if plugin-X sits forever waiting for
plugin-Y, and viceversa.  The plug-in loader could realize they
are waiting for each other and notify you of what's actually happening.

* A given plug-in could die, hang, or wait forever on external input.
(for example, a plug-in that retrieves the latest RDF from RAA.succ,
the server is down, and the plug-in sits forever waiting for data)
The plug-in loader should time-out, abort loading this plug-in,
notify as necesary, and after that, ignore all the subsequent plug-ins
that depend on the aborted plug-in.

* Say two versions of the same plug-in were installed in the system
and the system attempts to load both, which one would take precedence ?
Version numbers are needed when pre-loading,

There's no simple way plug-ins could do this right now, each coder
should have to deal with his own initialization code, and smooth
interaction with other coders' plug-ins is not guaranteed.

Another *possible* example:


<?xml version="1.0" encoding="iso-8859-1" ?>
<comment>added xml header</comment>

<plugin name="Test2_Plugin" version="1.0">
     <comment>dependspon means that the specified plugin must
             have been already started before attempting to load this one.
             Notice version numbers</comment>
     <dependson  plugin="I18N_Lang"  version="1.3.*" />

     <alias name="pairprog" path="plugins/interaction/pairprog">

     <comment>require would mean that the plug-in must be installed, but
             not necesarily loaded right now </comment>
    <require>plugins/test2/test</require>

    <comment>as Laurent suggested, a list of plug-ins to load before this
one </comment>
    <preload>
         <comment>preload by alias name</comment>
         <loadplugin name="pairprog" version="0.0.1" />
         <loadplugin name="interaction_drubylayer" version="0.0.2" />
    </preload>

     <comment>a list of plug-ins to be loaded after this one is started
</comment>
    <loadafter>
         <loadplugin name="Test2_guilayer" version="1.0">
    </loadafter>

    <module>FreeRIDE::Plugins::Test2</module>
    <properties>plugins/test2/properties.xml</properties>
    <install>plugins/test2/installer</install>
    <uninstall>plugins/test2/uninstaller</uninstall>
</plugin>


Just some ideas, once we polish them we could document
them on the Wiki for latter use.

cheers,
                   vruz