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

[Joel Reed <joelwreed comcast net>]

On Tue, Jan 04, 2005 at 10:39:46AM -0800, Mark Vakoc wrote:
> --- 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 test libexslt function.c and common.c as modules, both of which
use precompute afaict. so should be ok here.

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

when you speak of "registering" below, i was thinking of "callbacks". IOW,
libxslt saying "i can't find the appropriate element/function and am about
to throw up my hands" so if app has registered a plugin callback, i'll 
call it, give app a chance to load plugin, and try once more before quiting.

> > would the addition of a xsltEnablePlugins() call help at all? 
> 
> Yeah, whatever is done I hope there is a way to turn it off.

ok. Daniel also suggested integrating libxslt's security framework.

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

that's a great way to design something different from what i was trying
to acheive. really. i was just trying to put something different together:
the ability to compile/install an xslt plugin and instantly have it be
available for all libxslt users w/o application code changes. if this is
unwanted functionality, so be it - but it has lots of appeal to me.

jr