Re: [mod_fcgid] Cleaning up configuration directive names
On Tuesday 29 September 2009 4:20:49 pm you wrote:
On Tue, Sep 29, 2009 at 4:59 PM, Ricardo Cantu rica...@smartcsc.com wrote:
On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote:
ZombieScanInterval (leave alone until processes can be reaped
differently)
Working on a patch for this one. Don't want to duplicate work, so let me
know
if anybody else is working on this.
not me
I hope that, for Unix, processes can be reaped as with the MPMs: instead of
asking if a specific pid has exited (for each pid in the list), ask if any
pid has exited and if so find it in the list and handle.
Well, here it is. My patch to reap the children when they exit rather than
check the list for zombies. Before I take out the old logic for the zombie
scan I would like to hear some input on the code.
basically,
apr_proc_other_child_register() - to register a callback when child exits.
sigaction(SIGCHLD, sa, NULL) - to listen for children dying.
apr_proc_other_child_refresh_all(APR_OC_REASON_RESTART) - called when SIGCHLD
received so callback will be called on the correct registered child.
fcgid_child_maint - The callback. Cleans up the various lists and prints out
log info.
And that's it.
Index: modules/fcgid/fcgid_proc_unix.c
===
--- modules/fcgid/fcgid_proc_unix.c (revision 820820)
+++ modules/fcgid/fcgid_proc_unix.c (working copy)
@@ -58,6 +58,92 @@
static int g_process_counter = 0;
static apr_pool_t *g_inode_cginame_map = NULL;
+static void
+move_idle_to_free(server_rec * main_server, fcgid_procnode * procnode)
+{
+ fcgid_procnode *previous_node, *current_node, *next_node;
+ fcgid_procnode *free_list_header, *proc_table;
+
+ proc_table = proctable_get_table_array();
+ previous_node = proctable_get_idle_list();
+ free_list_header = proctable_get_free_list();
+
+ safe_lock(main_server);
+ current_node = proc_table[previous_node-next_index];
+ while (current_node != proc_table) {
+next_node = proc_table[current_node-next_index];
+
+if (procnode == current_node) {
+/* Unlink from idle list */
+ previous_node-next_index = current_node-next_index;
+
+/* Link to free list */
+ current_node-next_index = free_list_header-next_index;
+ free_list_header-next_index = current_node - proc_table;
+
+ break;
+} else
+ previous_node = current_node;
+
+current_node = next_node;
+ }
+ safe_unlock(main_server);
+}
+
+static void fcgid_child_maint(int reason, void *data, apr_wait_t status)
+{
+ fcgid_procnode *procnode = data;
+ int exitcode;
+ apr_exit_why_e exitwhy;
+
+ if (WIFEXITED(status)) {
+exitcode = WEXITSTATUS(status);
+exitwhy = APR_PROC_EXIT;
+ } else {
+exitcode = WTERMSIG(status);
+exitwhy = APR_PROC_SIGNAL;
+ }
+
+ switch (reason) {
+ case APR_OC_REASON_DEATH:
+ case APR_OC_REASON_LOST:
+
+ /* Log why and how it die */
+proc_print_exit_info(procnode, exitcode, exitwhy, procnode-main_server);
+
+ /* Register the death */
+register_termination(procnode-main_server, procnode);
+
+ /* Destroy pool */
+apr_pool_destroy(procnode-proc_pool);
+procnode-proc_pool = NULL;
+
+ /* Fix lists */
+move_idle_to_free(procnode-main_server, procnode);
+
+if (reason == APR_OC_REASON_DEATH) {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_DEATH, procnode-proc_id-pid);
+} else {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_LOST, procnode-proc_id-pid);
+}
+break;
+
+ case APR_OC_REASON_RESTART:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_RESTART, procnode-proc_id-pid);
+break;
+
+ case APR_OC_REASON_UNREGISTER:
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, NULL,
+ mod_fcgid: Pid: %d got APR_OC_REASON_UNREGISTER, procnode-proc_id-pid);
+break;
+ }
+}
+
static apr_status_t ap_unix_create_privileged_process(apr_proc_t *newproc,
const char *progname,
const char *const *args,
@@ -382,6 +468,10 @@
}
}
+/* setup handler for child death */
+apr_proc_other_child_register(procnode-proc_id, fcgid_child_maint,
+ procnode, NULL, procnode-proc_pool);
+
/* Set the (deviceid, inode) - fastcgi path map for log */
apr_snprintf(key_name, _POSIX_PATH_MAX, %lX%lX,
(unsigned long) procnode-inode,
@@ -457,7 +547,7 @@
apr_exit_why_e exitwhy;
rv = apr_proc_wait(procnode-proc_id, exitcode, exitwhy, APR_NOWAIT);
-if (rv == APR_CHILD_DONE || rv == APR_EGENERAL) {
+if (rv != APR_CHILD_NOTDONE) {
/*
Re: [mod_fcgid] Cleaning up configuration directive names
Jeff Trawick wrote: I borrowed a few ideas from my friends and botched the rest personally: (omitting FCGID prefix) leave alone AccessChecker AccessCheckerAuthoritative Authenticator AuthenticatorAuthoritative Authorizer AuthorizerAuthoritative Wrapper MaxRequestsPerProcess PassHeader It may just be me but I keep up mis-speaking Authorizer for Authenticator. The Authorizer I would have called the AccessChecker if that was not already used for another phase of checking. Maybe PreAuthAccessCheck and PostAuthAccessCheck. Barry
Re: [mod_fcgid] Cleaning up configuration directive names
On Wed, Sep 30, 2009 at 11:40 AM, Barry Scott barry.sc...@onelan.co.ukwrote: Jeff Trawick wrote: I borrowed a few ideas from my friends and botched the rest personally: (omitting FCGID prefix) leave alone AccessChecker AccessCheckerAuthoritative Authenticator AuthenticatorAuthoritative Authorizer AuthorizerAuthoritative Wrapper MaxRequestsPerProcess PassHeader It may just be me but I keep up mis-speaking Authorizer for Authenticator. The Authorizer I would have called the AccessChecker if that was not already used for another phase of checking. Maybe PreAuthAccessCheck and PostAuthAccessCheck. Access check, authentication, and authorization are the three Apache phases for modules to implement, hence the names. http://httpd.apache.org/docs/2.2/howto/auth.html
Re: [mod_fcgid] Cleaning up configuration directive names
I borrowed a few ideas from my friends and botched the rest personally: (omitting FCGID prefix) leave alone AccessChecker AccessCheckerAuthoritative Authenticator AuthenticatorAuthoritative Authorizer AuthorizerAuthoritative Wrapper MaxRequestsPerProcess PassHeader concepts need to be fixed or combined perhaps ErrorScanInterval - TerminationScanInterval IdleScanInterval - TerminationScanInterval (yeah, one directive for both concepts) ZombieScanInterval (leave alone until processes can be reaped differently) BusyScanInterval - TimeoutScanInterval simple adjustment BusyTimeout - RequestTimeout IdleTimeout - MaxProcessIdleTime ProcessLifeTime - MaxProcessLifetime IPCCommTimeout - IOTimeout IPCConnectTimeout - ConnectTimeout DefaultInitEnv - InitialEnv DefaultMaxClassProcessCount - MaxProcessesPerClass DefaultMinClassProcessCount - MinProcessesPerClass MaxProcessCount - MaxProcesses MaxRequestInMem - MemLimitRequestBody MaxRequestLen - LimitRequestBody OutputBufferSize - ResponseBufferSize PHPFixPathinfoEnable - FixPathinfo SharememPath - ProcessTableFile SocketPath - SocketDir SpawnScore - SpawnScoreSpawnCost SpawnScoreUpLimit - SpawnScoreLimit TerminationScore - SpawnScoreExitCost TimeScore - SpawnScoreDecayPerSecond
Re: [mod_fcgid] Cleaning up configuration directive names
On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote: I borrowed a few ideas from my friends and botched the rest personally: (omitting FCGID prefix) leave alone AccessChecker AccessCheckerAuthoritative Authenticator AuthenticatorAuthoritative Authorizer AuthorizerAuthoritative Wrapper MaxRequestsPerProcess PassHeader concepts need to be fixed or combined perhaps ErrorScanInterval - TerminationScanInterval IdleScanInterval - TerminationScanInterval (yeah, one directive for both concepts) ZombieScanInterval (leave alone until processes can be reaped differently) Working on a patch for this one. Don't want to duplicate work, so let me know if anybody else is working on this. BusyScanInterval - TimeoutScanInterval simple adjustment BusyTimeout - RequestTimeout IdleTimeout - MaxProcessIdleTime ProcessLifeTime - MaxProcessLifetime IPCCommTimeout - IOTimeout IPCConnectTimeout - ConnectTimeout DefaultInitEnv - InitialEnv DefaultMaxClassProcessCount - MaxProcessesPerClass DefaultMinClassProcessCount - MinProcessesPerClass MaxProcessCount - MaxProcesses MaxRequestInMem - MemLimitRequestBody MaxRequestLen - LimitRequestBody OutputBufferSize - ResponseBufferSize PHPFixPathinfoEnable - FixPathinfo SharememPath - ProcessTableFile SocketPath - SocketDir SpawnScore - SpawnScoreSpawnCost SpawnScoreUpLimit - SpawnScoreLimit TerminationScore - SpawnScoreExitCost TimeScore - SpawnScoreDecayPerSecond
Re: [mod_fcgid] Cleaning up configuration directive names
On Tue, Sep 29, 2009 at 4:59 PM, Ricardo Cantu rica...@smartcsc.com wrote: On Tuesday 29 September 2009 2:31:21 pm Jeff Trawick wrote: ZombieScanInterval (leave alone until processes can be reaped differently) Working on a patch for this one. Don't want to duplicate work, so let me know if anybody else is working on this. not me I hope that, for Unix, processes can be reaped as with the MPMs: instead of asking if a specific pid has exited (for each pid in the list), ask if any pid has exited and if so find it in the list and handle.
Re: [mod_fcgid] Cleaning up configuration directive names
On Tue, Sep 29, 2009 at 4:31 PM, Jeff Trawick traw...@gmail.com wrote: SpawnScore - SpawnScoreSpawnCost SpawnScoreUpLimit - SpawnScoreLimit TerminationScore - SpawnScoreExitCost TimeScore - SpawnScoreDecayPerSecond These names are pretty ugly :( Here is what they are for, in case that helps: They control the maintenance of a score that keeps process activity from overwhelming the system. A separate score is maintained for each application/class. The score is maintained by adding SpawnScore to the score for each process creation adding Termination score to the score for each process exit subtracting TimeScore from the score every second A new process cannot be created if the current score is SpawnScoreUpLimit. (It is probably fair to say that these directives were provided in lieu of a generally suitable algorithm to control spawning, and that in the long term the latter should be implemented.)
[mod_fcgid] Cleaning up configuration directive names
The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? FYI I include the list of directive names below. Regards, Rainer BusyScanInterval BusyTimeout DefaultInitEnv DefaultMaxClassProcessCount DefaultMinClassProcessCount ErrorScanInterval FCGIWrapper FastCgiAccessChecker FastCgiAccessCheckerAuthoritative FastCgiAuthenticator FastCgiAuthenticatorAuthoritative FastCgiAuthorizer FastCgiAuthorizerAuthoritative IPCCommTimeout IPCConnectTimeout IdleScanInterval IdleTimeout MaxProcessCount MaxRequestInMem MaxRequestLen MaxRequestsPerProcess OutputBufferSize PHP_Fix_Pathinfo_Enable PassHeader ProcessLifeTime SharememPath SocketPath SpawnScore SpawnScoreUpLimit TerminationScore TimeScore ZombieScanInterval
Re: [mod_fcgid] Cleaning up configuration directive names
On 09/21/2009 10:07 AM, Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? IMHO move them to the FCGI prefix namespace. Maybe we can think about keeping the namespace aware and the non namespace aware directives in parallel for some time to ease the migration for the users. Or provide them with a proper sed script to fix their config :-). Regards Rüdiger
Re: [mod_fcgid] Cleaning up configuration directive names
On Mon, Sep 21, 2009 at 4:18 AM, Ruediger Pluem rpl...@apache.org wrote: On 09/21/2009 10:07 AM, Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? IMHO move them to the FCGI prefix namespace. or FCGID maybe? Maybe we can think about keeping the namespace aware and the non namespace aware directives in parallel for some time to ease the migration for the users. yeah A user ought to be able to trivially adopt (and even unadopt) mod_fcgid for a while. Or provide them with a proper sed script to fix their config :-). too much effort to get some users to try it ;)
Re: [mod_fcgid] Cleaning up configuration directive names
On Sep 21, 2009, at 04:07 , Rainer Jung wrote: PHP_Fix_Pathinfo_Enable While we're on the topic, what the heck is up with the underscores in this one? Since when do we do underscores in directive names? Please don't do this. Thanks. -- Rich Bowen rbo...@rcbowen.com
Re: [mod_fcgid] Cleaning up configuration directive names
On Mon, Sep 21, 2009 at 8:18 AM, Rich Bowen rbo...@rcbowen.com wrote: On Sep 21, 2009, at 04:07 , Rainer Jung wrote: PHP_Fix_Pathinfo_Enable While we're on the topic, what the heck is up with the underscores in this one? Since when do we do underscores in directive names? Please don't do this. Thanks. In case it wasn't clear: That is ancient, pre-HTTPD history. We'll have a common prefix for the module's directives and CamelCase directive names. (Hopefully the existing directive names will be supported for some period of time (perhaps 2.3.x).
Re: [mod_fcgid] Cleaning up configuration directive names
On Mon, 21 Sep 2009, Ruediger Pluem wrote:
On 09/21/2009 10:07 AM, Rainer Jung wrote:
The names of the configuration directives of mod_fcgid are somehow
inconsistent. At least it's abit hard to remmber, that some directives
use a prefix FCGI, others use FastCgi (and most do not have a prefix for
a namespace).
I'm not sure, how important we take configuration compatibility with the
pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup
th einconsistent use of FCGI vs. FastCgi.
Comments?
IMHO move them to the FCGI prefix namespace. Maybe we can think about
keeping the namespace aware and the non namespace aware directives in parallel
for some time to ease the migration for the users.
Or provide them with a proper sed script to fix their config :-).
+1
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
Old computers never die, they just become video games
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [mod_fcgid] Cleaning up configuration directive names
On 21.09.2009 13:03, Jeff Trawick wrote: On Mon, Sep 21, 2009 at 4:18 AM, Ruediger Pluem rpl...@apache.org mailto:rpl...@apache.org wrote: On 09/21/2009 10:07 AM, Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? IMHO move them to the FCGI prefix namespace. or FCGID maybe? Maybe we can think about keeping the namespace aware and the non namespace aware directives in parallel for some time to ease the migration for the users. yeah A user ought to be able to trivially adopt (and even unadopt) mod_fcgid for a while. Or provide them with a proper sed script to fix their config :-). too much effort to get some users to try it ;) OK, so it seems the current proposal is: - prefix all configuration directives of mod_fcgid with FCGID Any complaints about using FCGID? - use CamelCase notation for all of them - keep the old ones around for compatibility - Is the best way of doing this by copying all the existing AP_INIT_* in fcgid_cmds? - Should we have a copied entry for each old directive in the docs, or should we only have entries for the new ones, and inside compatibility add a note with the old deprecated name? I would prefer this and maybe a general section about the renaming to put some moral pressure on people to fix their config. Any other name changes needed? I guess SharememPath - SharedMemoryPath would also be good. Concerning an sed script for migration support: I think we can probably deliver a basic one, but a full migration script would have to cope e.g. with configurations split up into diverse files. Regards, Rainer
RE: [mod_fcgid] Cleaning up configuration directive names
-Original Message- From: Rainer Jung Sent: Montag, 21. September 2009 15:49 To: dev@httpd.apache.org Subject: Re: [mod_fcgid] Cleaning up configuration directive names On 21.09.2009 13:03, Jeff Trawick wrote: On Mon, Sep 21, 2009 at 4:18 AM, Ruediger Pluem rpl...@apache.org mailto:rpl...@apache.org wrote: On 09/21/2009 10:07 AM, Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? IMHO move them to the FCGI prefix namespace. or FCGID maybe? Maybe we can think about keeping the namespace aware and the non namespace aware directives in parallel for some time to ease the migration for the users. yeah A user ought to be able to trivially adopt (and even unadopt) mod_fcgid for a while. Or provide them with a proper sed script to fix their config :-). too much effort to get some users to try it ;) OK, so it seems the current proposal is: - prefix all configuration directives of mod_fcgid with FCGID Any complaints about using FCGID? Not from me. - use CamelCase notation for all of them - keep the old ones around for compatibility - Is the best way of doing this by copying all the existing AP_INIT_* in fcgid_cmds? IMHO the best approach. - Should we have a copied entry for each old directive in the docs, or should we only have entries for the new ones, and inside compatibility add a note with the old deprecated name? The later. We shouldn't double the documentation. I would prefer this and maybe a general section about the renaming to put some moral pressure on people to fix their config. +1. Any other name changes needed? I guess SharememPath - SharedMemoryPath would also be good. Concerning an sed script for migration support: I think we can probably deliver a basic one, but a full migration script would have to cope e.g. with configurations split up into diverse files. My thought would be a sed script that the admin simply applies to every configuration file. Regards Rüdiger
Re: [mod_fcgid] Cleaning up configuration directive names
Rainer Jung wrote: Any other name changes needed? I guess SharememPath - SharedMemoryPath would also be good. Nope; refer to other directives. shmem is the abbreviation used by digest, but the usual convention is not identify as what it is, but what it does. E.g. It's the SSLSessionCache, it is the ScoreboardFile. We should consider renaming this to reflect what it is, the FCGIDProcessTrackFile or something similar.
Re: [mod_fcgid] Cleaning up configuration directive names
Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? A year or two ago I worked up this patch against what was then the CVS HEAD of mod_fcgid, because I found the variation of directive names too confusing when trying to figure out what to tune in a running config: http://people.apache.org/~chrisd/patches/mod_fcgid_auth/mod_fcgid-2rename-trunk.patch I'm sure there's lot to further adjust here, not to mention the fact that the patch doubtless won't apply cleanly anymore. I also have come to prefer FCGI as the prefix, to distinguish the module from mod_fastcgi. However, I'd throw it in as a set of initial suggestions for the renamed directives, at least. I recall making an effort to align the names to other httpd directives, as well as to each other, so that closely related directives grouped together by name. I also worked over the brief descriptions of what each directive does to try to make them more clear. So (using the FCGI prefix) we have various parallels to httpd directives, such as FCGIMaxRequestsPerServer, FCGILimitRequestBody, FCGITimeout, etc. Directives relating to the maximum and high-water-mark numbers of FastCGI processes are treated akin to similar directives for mod_dbd: FCGIMaxServersPerScript, FCGIKeepServersPerScript. Then there are lots of parallels within related sets of directives: FCGIIdleTimeout, FCGIIdleScanInterval, FCGIBusyTimeout, FCGIBusyScanInterval, FCGIErrorScanInterval, FCGIExitScanInterval, etc. I remember one hard part was trying to deal with the directive names relating to the spawn and terminate scores. I don't think what I came up with (FCGIServerExitValue, etc.) are very good, on reflection. It's very possible that spawn score is in fact perfectly adaquate as a description. Anyway, once some travel is done with this week, I hope to get cracking on gradually refactoring these old patches of mine. In the meantime, if others want to grab what they like and dump the rest, please do so. Cheers, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: [mod_fcgid] Cleaning up configuration directive names
On 21.09.2009 18:51, Chris Darroch wrote: Rainer Jung wrote: The names of the configuration directives of mod_fcgid are somehow inconsistent. At least it's abit hard to remmber, that some directives use a prefix FCGI, others use FastCgi (and most do not have a prefix for a namespace). I'm not sure, how important we take configuration compatibility with the pre-existing mod_fcgid (non-ASF) but I think we should at least cleanup th einconsistent use of FCGI vs. FastCgi. Comments? A year or two ago I worked up this patch against what was then the CVS HEAD of mod_fcgid, because I found the variation of directive names too confusing when trying to figure out what to tune in a running config: http://people.apache.org/~chrisd/patches/mod_fcgid_auth/mod_fcgid-2rename-trunk.patch I'm sure there's lot to further adjust here, not to mention the fact that the patch doubtless won't apply cleanly anymore. I also have come to prefer FCGI as the prefix, to distinguish the module from mod_fastcgi. However, I'd throw it in as a set of initial suggestions for the renamed directives, at least. I recall making an effort to align the names to other httpd directives, as well as to each other, so that closely related directives grouped together by name. I also worked over the brief descriptions of what each directive does to try to make them more clear. So (using the FCGI prefix) we have various parallels to httpd directives, such as FCGIMaxRequestsPerServer, FCGILimitRequestBody, FCGITimeout, etc. Directives relating to the maximum and high-water-mark numbers of FastCGI processes are treated akin to similar directives for mod_dbd: FCGIMaxServersPerScript, FCGIKeepServersPerScript. Then there are lots of parallels within related sets of directives: FCGIIdleTimeout, FCGIIdleScanInterval, FCGIBusyTimeout, FCGIBusyScanInterval, FCGIErrorScanInterval, FCGIExitScanInterval, etc. I remember one hard part was trying to deal with the directive names relating to the spawn and terminate scores. I don't think what I came up with (FCGIServerExitValue, etc.) are very good, on reflection. It's very possible that spawn score is in fact perfectly adaquate as a description. Anyway, once some travel is done with this week, I hope to get cracking on gradually refactoring these old patches of mine. In the meantime, if others want to grab what they like and dump the rest, please do so. I read your mail to late, but maybe that's not really a problem. I switched all names from XXX to FCGIDXXX except for FCGIWrapper, which is now FCGIDWrapper and PHP_Fix_Pathinfo_Enable is FCGIDPHPFixPathinfoEnable. I also added a table and some notes to the changes and the docs as well as a simple sed script (not very ingenious). I don't want you stop thinking about better names and I think most of the changes, like having a table in the docs and upgrade notes apply anyhow. Once we come up with better names and/or descriptions, I'll help in fixing mod_fcgid.c, README, CHANGES, manual and sed script. Regards, Rainer
Re: [mod_fcgid] Cleaning up configuration directive names
On 21.09.2009 17:47, William A. Rowe, Jr. wrote: Rainer Jung wrote: Any other name changes needed? I guess SharememPath - SharedMemoryPath would also be good. Nope; refer to other directives. shmem is the abbreviation used by digest, but the usual convention is not identify as what it is, but what it does. E.g. It's the SSLSessionCache, it is the ScoreboardFile. We should consider renaming this to reflect what it is, the FCGIDProcessTrackFile or something similar. I kept the original name (but with new prefix) until we decide on something better. Chris also wrote about his ideas for new directive names. Regards, Rainer
