Re: [development] Re: [consulting] Module to view/edit module weights
Remember that a mechanism similar to weights is used in UNIX/Linux init scripts (each daemon is given a 3 digit number and they are started in order).
How many people actually use that? I've never even seen such a 3 digit number in Gentoo. (I believe there is a dependency system or something, I don't ever need to look at it.)
All UNIX like systems that use the sysvinit (System V Initialization) use this. This is on UNIX V.4, Solaris, Red Hat, Mandriva, Ubuntu ...etc. # cd /etc/rc3.d/ # ls S10sysklogd S19mysql-ndb-mgm S20mysql S20ssh S25mdadm S89cron S99rc.local S11klogd S20makedev S20postfix S21mysql-ndb S50proftpd S91apache2 S99rmnologin These are just symlinks to the real script that does the start and stop which is in /etc/init.d/ for each service.
This is similar to update-rc.d in Debian/Ubuntu.
Never used it, I'm going to guess a majority of Drupal administrators haven't either.
That does not mean it is not there, just that you did not come across it. On Debian/Ubuntu, it is the update-rc.d that does it. http://wiki.linuxquestions.org/wiki/Update-rc.d On Redhat and family there is chkconfig. http://www.netadmintools.com/art94.html There is always the manual way as well: ln -s /etc/init.d/somedaemon /etc/rc3.d/S42somedaemon I am not saying this is the best or worst way, but the concept is used elsewhere.
On 6/16/06, Khalid B <kb@2bits.com> wrote:
Never used it, I'm going to guess a majority of Drupal administrators haven't either.
That does not mean it is not there, just that you did not come across it.
I think neil's point is that while it exists, he never needed to use it. And if that's not his point, I'll make it: I've only rarely had to edit init script numbers and I spent some time being in charge of writing installer software for a custom server based on jboss and apache and...but the init scripts that those guys shipped with were good enough and I didn't have to think about the numbers. Drupal should strive for a similar situation. Similarly, sticking a weightsUI onto admin/modules is distracting, confusing, and useless for 99% of Drupal users. It would be nice to be able to edit the weights, but I don't think it makes sense in the interface. If a module's weight is wrong in a situation- maybe log a bug to fix it or to reengineer an "after these modules" and "before these modules" system, but exposing control over the weights seems like the wrong solution even if it gets the job done in those 1% of cases. Regards, Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
On 6/16/06, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
On 6/16/06, Khalid B <kb@2bits.com> wrote:
Never used it, I'm going to guess a majority of Drupal administrators haven't either.
That does not mean it is not there, just that you did not come across it.
I think neil's point is that while it exists, he never needed to use it. And if that's not his point, I'll make it: I've only rarely had to edit init script numbers and I spent some time being in charge of writing installer software for a custom server based on jboss and apache and...but the init scripts that those guys shipped with were good enough and I didn't have to think about the numbers. Drupal should strive for a similar situation.
Good point and well stated. I only had to add them on occasion as well. For example to add the special device for a tape drive that does not get added automatically. In this case, it really did not matter what the number was, I just put it as late as possible.
Similarly, sticking a weightsUI onto admin/modules is distracting, confusing, and useless for 99% of Drupal users. It would be nice to be able to edit the weights, but I don't think it makes sense in the interface.
If a module's weight is wrong in a situation- maybe log a bug to fix it or to reengineer an "after these modules" and "before these modules" system, but exposing control over the weights seems like the wrong solution even if it gets the job done in those 1% of cases.
In the case of UNIX init script numbers, someone (not necessarily the machine user) decided the numbering scheme (the makers of the distro, or the packagers of the said daemon). I realize that no doubt the "load after" and "load before" functionality is a better (longer term) solution for the module order dilemma. The user interface can specify that (e.g. from a drop down list that has modules in it). Under the hood, the code could take the data and then sort the modules with the weight (simpler SQL, less code to load when not editing the order). Meanwhile, Barry's module is something that works today until that better solution is developed.
participants (2)
-
Greg Knaddison - GVS -
Khalid B