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

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]