[drupal-devel] settings inconsistencies

Vladimir Zlatanov vlado at dikini.net
Fri Feb 4 08:41:54 UTC 2005

> ...  remove player .module from it's "core" status and set it to
> "plugin" status this would allow it to  be changed to:
>     player.module (wmv,mpeg,asf,mpeg2) /burner /ripper /ogg
> Which would reduce the load on the core and give more flexibility to
> the module. The decision to make the  player.module part of the core
> was not a good one. The player.module should have been a fully
> seperate module to begin with. This goes back to my previous statement
> that "many" of the modules should not be extended but made replacable.
> This does not apply to every module and there should be a set criteria
> for "core" and "plugin".

I think there is a mixup of ideas. What is core, what is module, what is
plugin. Core is a tested and accepted bundle of apis and modules. It is
a distribution thing, rather a 'program he structure' thing. Modules, or
plugins (like the flexinode ones) are extensions using an api to be
included in a setup.

The module bloat - the number of modules in contrib is natural. People
have ideas, people want changes, people not always agree on changes,
others don't care or don't know about these changes, so  follows 
(nearly) duplicate functionality. Sometimes there are competing
modules/solutions, and it is not clear which one is better.
That is not a drupal phenomenon, it is very common when you have
the freedom to use and abuse code and the will to share the results.
The good solutions meeting some common requirements, like need,
popularity, quality end up in core - core drupal distribution.
Core functionality ends up in the other core - drupal apis, like the
file-api, it is lightweight and useful. I reckon there is term
overloading going on here.

IMO the project structure is clear and understandable, one of the main
reasons I actually ended up using and abusing drupal. If I don't like
something or require something extra - there is a clean way to do it.
Core/Contrib split is understandable.

The case with the settings is more of a UI issue, which needs resolving
by actually finding the best solution for the current structure, rather
than assuming it is failure by design (core design). I think the UI team
have some good ideas and attitude, but since I'm no expert there I can 
only criticise or complain, and I've done enough of that.


Vladimir Zlatanov <vlado at dikini.net>

More information about the drupal-devel mailing list