[Fusioninventory-devel] Speak about split of fusioninventory plugin for glpi

[Fabrice Flore-Thébault]

On 15-juin-10, at 10:16, Gonéri Le Bouder wrote:

> 2010/6/15 David DURIEUX <d.durieux at siprossii.com>:
>> Le Tue, 15 Jun 2010 00:08:24 +0200
>> Gonéri Le Bouder <goneri at rulezlan.org> a écrit:
>
>> Have all modules begin to be difficult because there is lots of code
>> for each module (and future modules), so if we split, it more easy to
>> maintain and have good code.
> On the other side, it will be more hard to maintain shared code  
> between
> the sub-plugins, you'll have to keep compatibility with different  
> revision
> of the modules (API and DB schema).
>

My point of view, as a user and a non-developer, is following (and  
engage only myself) :

I prefer to have only one plugin, as it is more clear to manage and  
maintain as a software on a production environment. You will loose the  
"visual" unity of the product, i am not sure it's a good idea.

You will have to describe and document the collection of plugins that  
can be used, and that's more than just activating (or not) a feature  
in a product.

If you have multiple plugins, then you have to monitor multiple  
timelines of releases, not only the releases of a single software.

If you have multiple plugins, during upgrade you get new questions to  
answser : which should be upgraded before the others ? or should they  
be upgraded all at the same time ?

I don't really understand the technical reason for splitting : if you  
have a stable release, and fix some things on a particular module, on  
a unitary plugin you will get a new version ; that's clear for  
everyone. If plugins are multiple, then you will get different version  
numbers for each ? That's complexity added (for what purpose ?).

A technical reason that i understand is : performance suffers from the  
fact that some code for unused features in the plugin is loaded. But  
to this the correct answer should be some work on the way glpi is  
loading code from modules, and i think we can live with this  
performance problem before it gets cleanly fixed.

Anyway, if it gets split, the benefits of the split should be  
explained on the forge.

-- 
Fabrice Flore-Thébault