Re: [FR-devel] FreeRIDE startup

[Laurent Julliard]

Horacio Lopez wrote:

> I am creating a plug-in for I18N, and I am testing on
> both  Linux and Windows.
> I am running exactly the same program, still,
> the initialization order of the plug-ins is different.
>
>
> This is because the load_plugins method
> iterates the directory entries without sorting
> them in any particular order.
>  
>
> Just to let people know they shouldn't
> always rely on the start-up order in a particular
> system, it may not necesarily always follow
> the same initialization order in other systems.
>
>  
>
> *_Now some comments on this:_*
> Some plug-ins will be using the Language plug-in
> for internationalization, and each one of them
> will have to wait until Language loads.
> Each plug-in coder will have to code his own
> initialization method.
> Would it make sense to store this synchronization
> data in the plugin.xml files ?
>
> say for example:
>
>  
>
> <plugin name="Test2_Plugin" version="1.0">
>   *<waitfor plugin="I18N_Lang" />**  *
> *  <startafter plugin="Test1_plugin" />*
>
>  
>
>   <require>plugins/test2/test</require>
>   <module>FreeRIDE::Plugins::Test2</module>
>   <properties>plugins/test2/properties.xml</properties>
>   <install>plugins/test2/installer</install>
>   <uninstall>plugins/test2/uninstaller</uninstall>
> </plugin>



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


> Explanation:
>
> The <waitfor> label waits for an initialization message
>
> from the specified plug-in. That doesn't necesarily means
>
> that plug-in has fully completed its initialization stage.
>
> The <startafter> makes this plug-in to start its initialization
>
> once the specified plug-in has fully completed its initialization.
>
> (maybe it's not all that clear, but we can talk more about it
>
> later if you find this feature to be useful)
>
>  
>
> This would help us avoid initialization mistakes
>
> and duplication of code. Don't know if it's feasible, and
>
> don't know if this makes things harder, just an idea.
>
>  
>
> If you like it, I will add it to the Wiki wishlists.
>
>  
>
> cheers,
>
>                  vruz
>
>  
>
>  
>
>