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

[Joel Reed <joelwreed comcast net>]

On Fri, Dec 31, 2004 at 07:43:55PM +0100, Igor Zlatkovic wrote:
> Joel Reed wrote:
> >I would like to address this issue specifically. it seemed to me
> >that most projects with plugins or modules, have one or two application
> >specific directories from which they will load such plugins or modules.
> >this path is determined at compile time.
> 
> Only on Unix. No program that I know of on Windows has ever done this.

i never posted more on this topic, as i was waiting for resolution
of libxml2 xmlmodule.{c,h} issues. i did think about the issues
at some length while waiting :). 

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.

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.

jr