Re: [xslt] [PATCH] xslt extensions as modules/dso's

[Igor Zlatkovic <igor zlatkovic com>]

Joel Reed wrote:
> i do agree compile time determined plugin paths would suck on windows
> boxen. i wanted to be able to support system-wide xslt plugins,
> application specific xslt plugins, and applications that wanted to prevent
> any DSO loading from happening even if such support was compiled into
> libxslt.

To be honest, hardcoded paths suck on Unix as well.

> my current code, yet to be posted, does the following:
>
> if xlst plugins are enabled at compile time in libxslt, 
> and if an unknown extension namespace is encountered:
>
> 1) if getenv("LIBXSLT_PLUGINS_PATH") returns a path, use it to load
> the appropriate plugin for the unknown extension namespace
>
> 2) on *nix only, if no LIBXSLT_PLUGINS_PATH defined, use
> compile time determined plugin path. for example,
> /usr/local/lib/libxslt/1.1/ on my test machine.
>
> i considered other windows mechanisms like the registry, but thought
> by using an environment variable, we'd have a lot less winblows specific
> code, and be able to use the environment variable on *nix as well
> so that we get the application specific plugins, and disabled plugins
> functionality as well.
>
> does that sound better? it did to me. i did consider relative paths
> on windows, but wasn't sure how well that would work in some of the
> use cases above, plus static linking, etc.

That is wonderful. Environment variables do wonders :) So easy to set up 
and noone ever complains about them. I have many of that sort. 
JAVA_HOME, CATALINA_HOME, ANT_HOME, it is nice to know that everyone 
feels like at home on my computer :-) :-)

Seriously, envvars are not a bad idea. Just if there is a fallback, make 
it relative on Windows.

Ciao,
Igor