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

[Benoit Mortier]

Le Sunday 20 June 2010 21:51:53 Fabrice Flore-Thébault, vous avez écrit :

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

Good ;-)

> 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.

Not right the whole stack is composed of several plugins but you install 
what you nedd thats more easy and correspond more to what people want in 
those situation, whay install thing that i dont need ?

Also think of the actual question "this interface is to complicated can i 
remove some parts"

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

you have some part that are core to get slower release cycle and you have 
plugins release that can have differents cycles, that perfectly normal
 
> 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 ?

those question are esay just upgrade what you really need, don't need to 
upgrade everything.

in the case of a new core release, it easy update core and then plugin if 
needed.

> 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 ?).

More stable code, more esay to fix bugs in plugins without touching the 
core.

> 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.

its already split ;-)

Cheers
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Contributor to Gosa Project : http://gosa-project.org/