RE: [FR-devel] FreeRIDE startup

[Rich Kilmer]

These are really great ideas.  I worked up a simple differentiation between
system and standard plugins already, but I think I know how this could be
done in a very simple (yet powerful) way using the databus as a triggering
mechanism.  The behavior will be fully encapsulated in the Plugin class
(yeah).  I'll get back to you guys soon with my thoughts.  BTW: I have the
Savannah link working (thanks Laurent!), so all code changed will be checked
in there.

Regards,

Rich

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of
> Horacio Lopez
> Sent: Sunday, January 27, 2002 12:21 PM
> To: address@hidden
> Subject: Re: [FR-devel] FreeRIDE startup
>
>
>
> ----- 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
>
>
> _______________________________________________
> Freeride-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/freeride-devel