Op zondag 11 juni 2006 17:06, schreef Jenny Hsueh:
I wonder, Ber - is your sympal script a starting point to focus on the "deployment" aspect that we can combine the energy with civicspace install
You state it correct: I beleive we should focus on the underlying part first. The underlying part being a set of Apis and scripts to install a site, or more then one site. You call that deployment. If you want more detail on why and how read on. Else: exit; :) And my scripts are indeed focused on deployment of Dupal site. They are a formalised, centralised, and reniced first version of all the "stuff" I had lying all over the place that I used to manage my growing flock of Drupal sites. I generalised these, rewrote them all in PHP (I used a lot of Ruby all over the place) and bound them in a single contrib. I use them with success to manage my host, now running 35 sites. It costs me no time to instal sites anymore, since I call the scripts from a webhosting environment (like Cpanel) called dischosting. Because I use them this way, they are still ery much focused on managing a multisite Drupal. But that is not the end-goal. The goal is, to get a solid installation system worked out. One that can be tied to any other system. Example to explain my point why a route bottom up is better: Firefox: Linux, OSX and the likes have perfect installation and software managers, in a whole range of flavours. Yet even 1.5 does not manage to hook into that properly. The upgrade system is still a private firefox thing. Now: Had FF designed a solid deployment system, instead of focussing on an interface for upgrading, all the linux and the OSX systems would have had a proper integration in their native software manager. And Then they could have built a standalone installer and upgrade system for the folks using MS. (MSwindows has no proper software manageing system). ut because it was chosen to be done the other way around, firefox has been in a broken state on Kubuntu, has not been going with the osX auto-updates, nor could Novell etc provide security updates for it. If Drupal goes the same way: design and develop a Drupal-only installer, then we will only serve a subset of people. While, when we develop a good deployment system, one cuold easily keep Drupal up-to-date with e.g. apt-get (on debian servers) or install it using native Plesk installers. While we could hook a Civicspace alike web-installer to it very well, for all those deprived of plesk, a linux installer, or some other webhosting environment. It should be *really* easy to tie my scripts to a CS instaler alike webform, or even to a single Drupal module (multisite_manager.module?). I did a proof of concept with a singel drupal site running of a special server on a special port, that had write permissions. I managed to install sites from within this one-ring-to-rule-all Drupal site. So you could even replace Cpanel or plesk with a special Drupal site! How cool is that! Bèr -- -- [ Bèr Kessels | Drupal services www.webschuur.com ] Drupal repareert wederom een kritiek veiligheidslek: http://help.sympal.nl/drupal_repareert_wederom_een_kritiek_veiligheidslek