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

[Mark Vakoc <thevakoc-xml yahoo com>]

--- Joel Reed <joelwreed comcast net> wrote:
> 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.

I would copy the implemtation of the xsl:document element (also registered
under other namespaces like saxon) and put that in an extension module with a
different namespace.  It uses the precompute functionality.

> 
> 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.

I think you misunderstood, I'm not sure what callbacks you are talking about.

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

Yeah, whatever is done I hope there is a way to turn it off.

> 
> 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?
> 

I guess what I'm saying is that a extension module shouldn't be that dynamic :)
 That is avoid the logic to load it on demand and instead require that the
caller "register" the plugin module within their application rather than have
libx* try to find it on it's own.  Think of adding custom i/o handlers to
libxml2.  How can that be dynamically discovered?  

I actually proposed something along these lines a whiles back
(http://mail.gnome.org/archives/xml/2004-April/msg00247.html).  

I think we should provice an API for loading modules, a way of defining a
module (i.e. making an entry point available to libx*) with init and term
functions, and allow that module to register it's custom i/o handlers, xslt
extensions, perhaps someday encoding conversion functions, etc. and not have
the libraries attempt to dynamically load/find functionality when needed.