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. :) Cheers, Gerhard
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 is contributed. 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 became available. 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. :-) ..chrisxj