On 11/28/07 2:54 PM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
> as in ap_register_include_handler?
No. As in want to have other variables in addition to the environment and
the "special" httpd ones (like DATE_LOCAL, DOCUMENT_URI).
>> Pseudo code:
>
> Where would you propose to use it?
Like:
<!--#if expr='"$FOO{bar}" = "baz"' -->
this is baz stuff
<!--#elif expr='"$FOO{eggs}" = "spam"' -->
<!--#include virtual="/spam.html" -->
<!--#else -->
Other crap
<!--#endif -->
<!--#echo var="SUPERSPECIALSTUFF" -->
Sorta like this:
http://esi-examples.akamai.com/viewsource/geo.html
But in ssi.
In reality, there needs to be a way to tie "environment values" to
functions, rather than jut r->subproccess_env. Or maybe call them something
else, but in a way that all modules (rewrite, include, etc.) can access,
just like they do "environment."
ap_get_env(r, "DOCUMENT_URI", &val);
A provider for this would just return r->uri, but
ap_get_env(r, "BAKINS", &val)
Would call the provider I registered.
And this would "just work" in other modules because they would always use
ap_get_env (and ap_set_env, if needed). Would be nice if env was more than
just key = value, ie, FOO{bar}.
However, this would require redoing a significant amount of stuff - modules
and config practices. I, currently, just have need of it for ssi, but just
wanted to get a discussion going.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
