What design would be better for a module?
- a module per application
In this model each application is distributed as a module and that module contains all needed for application to work.
- download, activate & run... just easy & fun!
- it's posible to make up a system full of modules (no need for install anything not being itself a module) ** mainly in a happy world nowadays **
- it's posible to install and deinstall software on demand (i.e when this event happens activate this module)
- autocomplete, all needed is in the module, install is just a matter of copy&paste
- you will have a lot of files duplicated in your storage (imagine a library file used for a lot of applications)
- Files in modules may hide files in the system or other modules when activated
- maybe library hell or library mesh!
- a light module per application
In this model each application is distributed as a module but that module contains only application files and maybe dependent resources not very common or specific to the app.
- often just activate and run but... sometimes you have to work installing extra things
- you use common resources in the system
- better use of storage due to lowering duplication
- this model requires the existence of 'common resources modules' or coexistence with alternative installing methods (i.e. usm)
- Difficult to set what have to be inside and what outside the module (How common is a resource?)
- a module per collection
In this model each modules packs a collection of software for a common use, i.e. development, office, painting, electronics... It will include all files needing for all software in the module.
It's the same concept of first model but with a compromise between pros and cons just packing related software in a rational way.
- activate and run
- profile oriented, you can build and distribute modules for specific profiles of users or niches (i.e programmers, musicians, artists, writers...)
- modular (you can evolve and grow in a modular way, even porteus may be modularized as it is already but to a greater extent)
- you use common resources in the system (they will be a module!)
- better use of storage due to lowering duplication (a compromise)
- requires planning to decide what to include in each module
- module clashing (target users need software not available in a module and make a slighty different module or maybe different modules for different targets share common software)
- any other model ?