[consulting] Planning for future versions

[Kieran Lal]

On 8/17/07, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>
> <snip>
>  I'd be interested in seeing a prioritized list of possible next steps for
> mass hosting services built on Drupal.


1) Integrate paranoia module into core, or prevent a PHP Filter from being
added in settings.php.  This impacts security and performance, two concerns
for hosting companies or Application Service Providers.

2) Extend the services in Drupal module so that hosting companies could get
remote information from all their sites.  We used to configure CivicSpace
distro to ping back to CivicSpace.  Drupal.org used to do this as well.  It
would be good if service providers could get information from their sites.
It would be helpful if distribution profiles maintainers could know what
sites are using their distribution.  If this was extensible so that service
providers could also send information to site that would also help.  "We are
going to upgrade your site" "We have applied the latest security updates".
This could include OpenID login to securely transmit this information back
to Drupal.org, hosting provider, etc.  Some of this framework is in place
with updates now in D6, but it needs to be even more extensible.

3) Drupal bootstrap is too big and sometimes causes problems with hard coded
paths for required modules in the system table.
This forces me to include required modules in /modules but I'd rather
include them via /sites/domain/modules/required.  When you are upgrading
sites dynamically as we do with taskmanager, CivicSpace's provision
platform, we have to move from one web server document root (Drupal 4.7) to
another web server document root (Drupal 5).

e.g. /var/www/drupal4-7/modules/system.module  when changed to
/var/www/drupal5/modules/system.module prevents Drupal from bootstrapping.
So you are required to keep the modules relative to the Drupal root in
/modules.

4) Greater control over which files are bootstrapped to facilitate
upgrades.   With versioned modules now available from Drupal.org we
frequently are updating modules.  Ideally we could have multiple versions of
modules within the Drupal bootstrap path, if we could dynamically specify
which module instance is loaded.  So if Drupal found 5 copies of
content.module it could choose to either load the latest version of the
module based on the version number in content.info or you could configure
the Drupal bootstrap to load specific modules.

This is very useful when trying to do automated testing, or provisioning the
latest version of a module by downloading it automatically to the web
server.

Right now, having multiple versions of modules in the bootstrap path can
cause conflicts.  It also means a server side OS process must remove old
modules or a system administrator must do this.  My preference would be to
make this all configurable through the web interface or server side policy
and avoid additional server side processes.  Basically, you could obsolete
modules, and even non bootstrap core code, in place.

Cheers,
Kieran


--
> Dries Buytaert  ::  http://www.buytaert.net/
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>



-- 
To strive, to seek, to find, and not to yield.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20070817/bd9e1702/attachment-0001.htm