RFC: replace r->subprocess_env was Re: Patch for implementing ap_document_root as a hook

["Akins, Brian" <Br...@turner.com>]

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

Re: RFC: replace r->subprocess_env was Re: Patch for implementing ap_document_root as a hook

[Jakob Goldbach <ja...@gmail.com>]

> Thoughts?

I like it.

I prefer this generel env. API rather than making
ap_add_{common,cgi}_vars hook'able.

/Jakob