Profiles vs Use-Cases

Hi,

well, I hope this gets read with all the mails flying back and fro on the devel-list ;)
I believe, that there is a better way to implement Profiles then the current one. In fact, I believe that there is a better way to manage quite a number of module installations. I know this is quite a bold beginning - but please, bare with me for the moment.

In my experience most users don't want to install module xyz - they want to add a certain functionality or fulfill a certain use-case. (Even if it is only one module) ... Well, let's give it to them:

A use-case would simply be a set of module-requirements and (perhaps) a use-case-module that chains those modules together.
Want an example? Think of WYSIWYG+IMCE+IMCE mkdir -> use-case: "WYSIWYG-editor with image management". In contrast to profiles, use-cases could be installed into a running system.

The (in my eyes) perfect combination would be use-cases together with an auto-installer (install use-case, automatically downloads and installs required modules), alternatively an use-case could contain the required modules. (See section later on).

What would this solve?
1) It would solve anything profiles do - simply add a use-case to the installation, and you have finished your profile.
2) It would be an extension to the module-system. Modules could be installed separately or in combination.
3) It would be an extension to profiles - as use-cases could be combined or themselves inherited (use-case: WYSIWYG-editor with image management and simple edit > extension of the above use-case)
4) It would allow to move optional modules from core - simply provide a "standard use-case" (as standard-download) which includes optional modules and keep core restricted to "required" parts. (Please remark that I am not talking about a minimal core with respect to functionality, but with respect to "no optional parts").

The easiest possible implementation of an use-case would be a module, that provides (nearly) no code, but requires a list of other modules (Meta-module?). More complex implementations would e.g. add auto-installer support, version checks, etc

In fact, use-cases could also present a small benefit wrt the current "quality/duplicity of modules" discussion:
Simply provide a set of "official" (or common) use-cases.
Modules can (and will) evolve just as they are doing now. And the official use-cases can combine the best set of modules for the given use-case (see WYSIWYG). Another module is taking over? Fine. Update the use-case, present an update-path, and your done.

Then provide a list of "unofficial use-cases" (similar to normal modules) - Well, evolution has to take place for use-cases too. From there use-cases could be promoted (or demoted).

And yes, I would be willing to develop use-cases (and, should it be wanted, the auto-installer) and help with maintaining the list of use-cases. But - Use-cases have no sense, if the Drupal-maintainers vote against them (and I don't like working for the trash).

Regarding auto-installers: Yes I know, that most experienced administrators dont like automatic installers (for good reasons) - but they would be optional and a simple add-on for non-experienced (or lazy) users. Use-cases would work without - experienced users should be able to install modules themselves ;)