Re: [xml] proposal - adding dynamic library support to libxml2

[Daniel Veillard <veillard redhat com>]

On Tue, Apr 20, 2004 at 12:31:36PM -0600, Mark_Vakoc peoplesoft com wrote:
> I think there is significant advantage to adding the ability to
> dynamically load modules into libxml2 (and also libxslt) that could
> register I/O handlers, XSLT extensions, etc from xmllint/xsltproc.  Of
> course this is a platform-specific mess but others do it so why can't we
> :)

   Right, thanks for opening this nice rathole ;-)
I have been toying with the idea for some time (less than a couple of years),
mostly for XSLT extensions (script support and XSLT extensions), but
also as a way to minimize the size of the default library for those who
only want to parse an XML file.

> Attached is a proposed framework for accomplishing this along with an
> implementation for win32.  I don't have the experience with other
> platforms but I would imagine it wouldn't be that hard to plug those in.

  I glanced at the code, looks fine, I will be travelling and very busy for
a week, so I'm not sure I will be able to do the Linux side.
One of the things I'm wondering about is having undefined entry points
and being able to resolve them dynamically by loading an extra lib.
I'm not sure that possible reliably, and since I must preseve the ABI
compatibility this might be hard...

> For testing purposes I added a parameter to xmllint called --dynalib
> that would load the specified library and call an init function.  Prior
> to exiting xmllint calls a cleanup function that first calls a cleanup
> function in each library (if present) and then unloads the library.  The
> cleanup call should probably be moved into xmlCleanupParser() if
> accepted.

  One thing I'm not sure about: why do you use a macro aliasing the
start/stop library functions ? Would multiple shared libs with the
same start/stop library functions not break loading multiple extensions ?

> Also added a parameter WITH_DYNALIB in xmlversion.h[.in] that would be a
> compile time option for enabling this, though it will not cause an
> problem to complile in the support on platforms that aren't yet
> implemented.

  makes sense.

> A dynalib library would implement the functionality roughly like
>
> #include <libxml/dynalib.h>
>
> int XMLCALL XML_DYNALIB_INIT() {
>       /* do whatever you need to do 
> }
>
> void XMLCALL XML_DUNALIB_TERM() {
>       /* do whatever cleanup you need
> }
>
> This is not by any means production code and would likely go through API
> changes but I wanted to share early with the list for discussion.

  yes let's open the discussion :-)

> Attached is dynalib.h, dynalib.c, and a minimal patch to xmllint to use
> the functionality.  This has been more or less tested on win32 and it
> works but like I said this is really discussion code rather than
> production code at this point.

  Why not, I'm not 100% sure on the use cases at the libxml2 level,
but for libxslt it makes sense. I also think that Aleksey did something
similar for xmlsec we would need to look into this to share code and
checks requirements and portability,

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/