[consulting] Planning for future versions

[Boris Mann]

On 8/17/07, Kieran Lal <kieran at civicspacelabs.org> wrote:

> 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.

This is what I was talking about with a set of "dashboard" modules and services.

And this would all be in contrib modules in any case, nothing to do
with core, and no changes to core needed.

> 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.

This is Apache configuration. Hostmaster upgrades by switching a base
drupal core to include from, so every upgrade is, in fact, a separate
docroot. More than one way to skin this cat, no changes needed to
Drupal core as far as I can see.


-- 
Boris Mann
Office 604-682-2889
Skype borismann
http://www.bryght.com