[development] Restructure Core Module Support [ was: Time to remove
poll module from core]
chris at tinpixel.com
Mon May 1 19:34:14 UTC 2006
Robert Douglass wrote:
> Its presence in core is holding up its own development.
> cool idea. And let's rm archive.module and maybe blog.module too. :)
As someone mentioned in the thread this posting was derived from, moving
modules out of core often means they fall of the face of the earth and no
longer get support and updates. That's not good.
On the other hand, we cannot add every valuable module which has or needs good
on-going support to core. Various solutions to this have been proposed
before. Here's mine for this year:
=> Core should be core required files and code only. For the rest of this
posting, I will call these the "framework files" or just "framework," but the
name is mostly not important to me. It's just for clarity.
=> There should be a group of the most useful, best coded modules which are
maintained and supported like the core itself. For the rest of this posting,
I will call these the "core modules"
=> There should be a contrib repository for any and all other code
contributed by anyone with a CVS account. Support and maintenance is whatever
Why: this removes the tension of trying to keep "core" small by removing some
useful and important modules in order to add newer, more "interesting"
modules, yet at the same time provides a reasonable library of "core modules"
which can be relied upon from release to release by the community. As we grow
more expert developers, the size of the "core modules" library can grow, too.
Not everybody is using Drupal the same way. This creates an inherent
continuing conflict over which modules should be in what we now call core. It
causes frustration when a module that a dozen sites depend on get dropped from
core and a new release of Drupal comes out.
Is Drupal a full-featured CMS out of the "core" box? Why bother struggling
with that question and instead admit that Drupal can do a variety of different
things with the right modules.
Moving to a framework with installable profiles (collections of modules) for
different uses will help move Drupal into wider usage, and at the same time,
provide a better upgrade path for current installations. It will also
encourage more API-style thinking when developing, since the "framework files"
will be mostly APIs upon which all else is built. This would result over time
in the framework becoming more generic and more optimized, which should allow
for more creative and unusual modules to be built on top of it.
It might even be sane to say that without installing at least one profile or
bundle of modules on top of the framework, it wouldn't even function at all.
For sake of example, the "download Drupal" page could offer the new user (say)
3 bundles or profiles, each a collection of the framework files plus only the
modules needed to implement that profile. They might be: CMS, blog, and
e-commerce site. Or something else.
The same serious attention that is given to today's "core" would be given to
both the "framework" and the "core modules" tomorrow. The initial division
would not change the total amount of code maintained but would allow more
modules to be added without pushing others out as the developer manpower
I think this sort of division would make life simpler for many existing sites
who face upgrades, as well as make Drupal less intimidating for newcomers
looking to start building. And, of course, scratching my own itch, this would
make my life much simpler, because I use very few of today's "core" modules,
but use lots of other modules outside of them. I want a clean framework to
build on top of and I'm willing to do the work to make it happen.
Ok, that's my few minutes on the soapbox for this quarter. :-)
More information about the development