[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FR-devel] FreeRIDE startup
From: |
Rich Kilmer |
Subject: |
RE: [FR-devel] FreeRIDE startup |
Date: |
Sun, 27 Jan 2002 14:30:51 -0500 |
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