Hi, I apologize right in front - I'm new to Drupal development (so neither to programming nor to php/webprogramming), nevertheless I want to voice some of my concerns regarding "core" vs "profiles", as the problem was mentioned in the discussion /Drupal 7 "When it's Ready"/. Matt Chapman schrieb:
You may say, 'What about modules that are so generic that they are used in most any site?' I'd suggest that those are exactly the sorts of modules that should be included in Core. We're seeing this happen with CCK, and Views seems poised to follow shortly. We could even make the criteria for core eligibility more explicit: If a module is used in EVERY supported profile, then it should be moved to core in some form. (And the converse: if a module is not used by any supported profile, it should probably be removed from core.)
One thing that would really help this is more street cred for profile maintainers. However about some front-page case studies for a couple profiles?
I am a big fan of modular development - and in my eyes modular development means: Keep core as minimal as possible and provide modules and module-packs. For Drupal this would mean: A minimal core (might include minimal CCK and Views (API), but e.g. not Blog or Forum) that is required, abd not a single optional module. Then provide some "standard profiles/usecases". Most users would download the standard profile (thus including e.g. Blog, Forum and Views UI). Replace the standard download link with a link to the standard profile. What is the difference? Core is more critical then optional modules. Thus every module-update has to be part of a core-update - while updating single non-core modules is far easier for both, the developer and the user. A minimal core thus provides the highest flexibility. You can e.g. see that in Drupal - core modules tend to develop much slower then contrib ones. This is ok, but does Drupal really need a large Core? For the average user (and even the average developer) a minimal core with a standard profile wouldn't change anything. This would change the scope of profiles, but I think it would be for the best.
It's not so important to users that module X be available, but that feature Y be provided by some module; preferably with an upgrade path from module X, but that is secondary from a development perspective.
I agree - and believe that this again is an argument in favor of "minimal core, maximal profile".
Rather than golden modules, what we need are golden 'use cases.' Perhaps this takes the form of supported Profiles or Patterns. (I'll use the term 'profile' to mean any means of collecting modules and configurations for implementing a specific end-user functionality. I think installation profiles as currently supported by Drupal are severely lacking, having abandoned one in favor of database dumps for the time being.)
I agree. Profiles would need to be changed into something more generic. In fact, an automatic download tool in combination with use-cases would solve even more problems: Use-cases (or profiles) could be downloaded/selected, and the needed modules are automatically downloaded and installed. I agree, that quite a couple of professional webmasters wouldn't use automatic downloaders out of the box - but they should be able to download needed modules by themselves, provided the use-case lists the needed modules. A use-case could e.g. be a module with requirements, but without content (define what modules you need for the given use-case, possible link them together, but provide no functionality for yourself). If a use-case needs functionality that is not defined in any module - add a corresponding module. If the functionality is only needed in the given use-case, add it to the use-case module. This would allow a much more flexible combination of use-cases/profiles, it would allow for extending use-cases (e.g. Blogpage, Reviewblog extends Blogpage, etc)
Finally, supporting profiles instead of modules makes the system less susceptible to single points of failure. It takes less technical expertise to maintain a profile than it does to maintain a module. If I maintain the Community Events Management profile, and there's no e-mail reminder functionality available for Drupal 7, I can petition 3 or 4 different module developers to upgrade their module, or I can try to organize some developers to create a new, better one, to leverage the new DX features of Drupal 7.
Again: I believe that this is an argument pro "profiles" and against "core" as it would be easier to maintain a set of use-cases/profiles with a minimal core, provided use-cases could include other use-cases. -- Mit freundlichen Grüßen / Best regards / Saludos cordiales *Sebastian Nerz* ___________________________________________ *Orestes* Eduard-Spranger-Str. 56 D-72076 Tuebingen - Deutschland Of. : +49-7071-56519-30 - Fax : +49-7071-56519-31 www.orestes-sol.com <http://www.orestes-sol.com/> s.nerz@orestes-sol.com <mailto:s.nerz@orestes-sol.com> ___________________________________________