<br><br><div><span class="gmail_quote">On 8/17/07, <b class="gmail_sendername">Dries Buytaert</b> <<a href="mailto:dries.buytaert@gmail.com">dries.buytaert@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<snip><br> I'd be interested in seeing a prioritized list of possible next steps for mass hosting services built on Drupal.</blockquote><div><br>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.<br><br>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.
<a href="http://Drupal.org">Drupal.org</a> 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
<a href="http://Drupal.org">Drupal.org</a>, hosting provider, etc. Some of this framework is in place with updates now in D6, but it needs to be even more extensible.<br><br>3) Drupal bootstrap is too big and sometimes causes problems with hard coded paths for required modules in the system table.
<br>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).<br><br>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.
<br><br>4) Greater control over which files are bootstrapped to facilitate upgrades. With versioned modules now available from <a href="http://Drupal.org">Drupal.org</a> 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 <a href="http://content.info">content.info</a> or you could configure the Drupal bootstrap to load specific modules.
<br><br>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.<br> <br></div>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.
<br><br>Cheers,<br>Kieran<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>Dries Buytaert :: <a href="http://www.buytaert.net/">
http://www.buytaert.net/</a><br><br>_______________________________________________<br>consulting mailing list<br><a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br><a href="http://lists.drupal.org/mailman/listinfo/consulting">
http://lists.drupal.org/mailman/listinfo/consulting</a><br></blockquote></div><br><br clear="all"><br>-- <br>To strive, to seek, to find, and not to yield.<br>