This idea has been rattling around in my head off and on for a while. What is we replaced all the r->subprocess_env with something a little more interesting...
General "environment" API: /* "directly" set an env variable. Will always show up in env list */ apr_status_t ap_set_env(request_rec *r, const char *key, const char *val) /* Get the value of an env var. */ const char *ap_get_env(request_rec *r, const char *key And the interesting ones: /* Set a handler for a given key for env variables. Can choose whether or not the key shows up in the list. */ apr_status_t ap_set_env_handler(constchar *key, ap_env_func *func, int show_in_list) /* Return a list of available (exposed) env variables suitable for iteration */ apr_array_header_t *ap_env_list( request_rec *r, const char *key) ap_env_func would be : const char* my_env_handler(request_rec*r, const char* key) This would allow most env variables to be overridden easily. Also, many env variables could be set "lazily," ie, only calculate it when someone actually needs it. A good example of this is when you occasionally use UNIQUE_ID and only want the calculation to be done when you actually need it, not on every single request. The handler could cache it's results if it wanted. We may want a flag to say cache is okay or not. Or do caching in env itself... The actually handler, could actually be a hook. For example, the handler for "DOCUMENT_ROOT" could actually be a wrapper around a hook. Thoughts? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
