Re: [xslt] [PATCH] xslt extensions as modules, take 2

[Joel Reed <joelwreed comcast net>]

On Mon, Jan 03, 2005 at 10:36:52AM -0800, Mark Vakoc wrote:
> 
> --- Joel Reed <joelwreed comcast net> wrote:
> > On a plugin enabled libxslt, when a function, top-level, or element
> > can't be found in the appropriate standard hashes, we attempt
> > to find a plugin like this:
> 
> It seems to me you are pushing the module handling too high in the food chain. 
> Why not just create a stub for regular expressions and use the module loading
> during it's init functions to load any required third party libraries and if
> found register the available functions?

just to be clear: i am trying to create a general, extensible way to create
libxslt extensions/plugins not just a workaround for exslt:regexp.

i could be wrong, but i am hoping that this plugin option:
  1) takes some burden off of libxslt maintainers
  2) makes it easier for people to write extensions/plugins

> A potential problem I see is that extension functions I don't believe are
> always found during stylesheet compilation but rather during the execution.  I
> know I've had typos before when calling custom extensions and those are caught
> only while applying the stylesheet.  If the extensions are only registered
> during runtime you prevent them from being able to use the precompute
> functionality normally called when compiling a stylesheet.  This also would
> cause havoc perhaps with the extension module's init callback members

i have tested init callback members - they work fine. as to potential problems
with precompute functionality, do you have a test case i can work with? i've
tested the current testsuite with exslt as all modules, and libexslt as normally
used and have found no differences. i will gladly test any additional 
scenarios.

> Seems to me the logic should be handled more by the user application than
> within libxslt itself.  For years my application, based on runtime information,
> loads particular xslt extensions depending on the environment they are run in. 
> This is done prior to actually compiling/using any stylesheets.  If I were to
> port the application to another platform it would me nice to have platform
> agnostic module APIs, but I wonder if the module loading isn't better off being
> the responsiblity of the library's consumer or within prebuilt libraries such
> as libexslt.

i did consider callbacks which could be used on a per-application basis,
but decided this would limit the usefulness of multi-app plugins, given
each app would have to implement the callbacks.

would the addition of a xsltEnablePlugins() call help at all? 

honestly i can't see how dynamic plugins could be implemented within libexslt,
unless you _know_ about all implemented plugin functions, elements, etc.  at
startup - which defeats the whole point of load-on-demand plugins.  how did you
see that working?

jr