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

[Daniel Veillard <veillard redhat com>]

On Tue, Dec 21, 2004 at 10:15:41PM -0800, Mark Vakoc wrote:
> I like the concept of defining exslt as an optional library, and hope that
> xsltproc will use this functionality to load the module by default but
> gracefuly accept the library not being present, but am concerned about the need
> for so many librarys, or at least hope this is an option, and will continue to
> support creating a single shared library (.dll on windows) for libexslt that
> contains all the functions/elements implemented, rather than having to have one
> library for each module (namespace) implemented by exslt.  Perhaps an option to
> configure.js on win32?  Also would be nice to staticly link exslt into libxslt
> as well, even when libexslt is built as a dynamic library (.dll on windows).  
> 
> One of the problems I've always faced is win32 apps that decide it is proper to
> install their DLLs to the windows or windows\system32 directory, automatically
> pushing those higher in the LoadLibrary search path than I'd like.  (Note:  the
> LoadLibrary path lookup is complex and very OS dependent).  This lead to my app
> loading an older/mismatched version of the libx*.dll libraries rather than
> those supplied with m application (my executable expects the targeted libraries
> to be in the current path, not necessarily the path of the initiating
> executable).  For this reason I build my dynamic libraries as
> libxslt.1.0.16.dll et. al, been meaning to send a patch making this an option
> for configure.js.
[...]

   sounds like a possible option too yes.

> > The only question i have is about what to do with libexslt. When modules
> > are enabled there is really no use for libexslt. Part of me feels
> > like the best approach would be to make this a libxslt2 thing. libexslt
> > _could_ be ripped out and replaced with a series of exslt modules, with 
> > some base set and then additional extensions. i'd like to do the regexp
> > extension based on prce for example, if this patch is eventually
> > accepted.  

  Well, I can't garantee there will ever be a libxslt2. The only promise I
have done and have to garantee is that apps will still compile (no API change)
and run even if compiled against an old version. Just think of the gazillion
PHP5 installations linking to libxslt and libexslt.

> > Looking forward to receiving feedback on the implementation,

  seems you tested it on Linux, feedback on Windows would help, otherwise
from a code point of view it should be relatively easy to garantee the 
API abd ABI stability which are my main concerns.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/