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

[Mark_Vakoc peoplesoft com]

> -----Original Message-----
> From: xml-admin gnome org [mailto:xml-admin gnome org] On Behalf Of
Daniel
> Veillard
>    Right, thanks for opening this nice rathole ;-)

No problem, I'm good at that.

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

I can take a hack at it based on what I find from apache.

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

I assume you mean so that components of libxml itself can be stored in
separate libraries and only loaded when needed.  Actually the msvc
compiler has built in support for this called delayed load linking.  It
allows you to link against a library but only load it when a function
from that library is first used, throwing an exception if the
function/library could not be found.  Outside of native compiler support
I think it would be rather difficult and messy to implement this within
the library:  the existing functions would need to be stubs that call
the xmlDynaLibSymbol to get a pointer to the function.  It would work
but would be verbose and messy and not sure if the gain is worth the
pita given the number of entry points into the libxml API.

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

The macro was just to make it easier on the implementer to get the name
correct.  Multiple libraries would work fine as you can have the same
function defined and loaded from different libraries within the same
process.

I made some changes so that you can optionally specific the function
name in the call to xmlDynaLibRegister with a fallback to the default
name if NULL is passed in.  
        int xmlDynaLibRegister(const char* path, const char* name);

I also changed it to a single entry point function rather than two, with
a parameter that specifies the operation (load or unload).  Would also
allow having two entry points in the same library if desired (not sure
why, but is now possible). 

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

I thought about where it should belong, libxslt or libxml, and the nice
thing about putting the functionality into libxml2 is I can use my
custom i/o handlers with a vanilla xmllint and both libraries can
benefit from it.

I also added two new items.  A function called xmlDynaLibFind(const
char* path) that returns the xmlDynaLibPtr for a library (if it has been
loaded) and the option that gets passed into the entry point function
that allows the dynamic library to print version info, etc to a FILE*.
The thought there is it could be useful for the --version flags and also
thought the exslt module could be migrated to use this functionality.

I'll post the updated files in a later e-mail (will probably get flagged
as suspicious if I attach them to this letter).

Mark
if