[development] Core vs profile [was: Drupal 7 "When it's Ready"]

[Sebastian Nerz]

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 at orestes-sol.com <mailto:s.nerz at orestes-sol.com>
___________________________________________