Re: [xml] Re: The DSO dilemna

[Joel Reed <joelwreed comcast net>]

On Thu, Dec 30, 2004 at 03:49:54AM -0800, Aleksey Sanin wrote:
> > Aleksey what is you view point on this ? Do you think the suggested 
> > API would be sufficient ? Would it be worth changing XMLSec to also 
> > rely on it ?
> How many and which platforms are supported by Joel's code? How much
> was it tested?

right now there is code for win32, dlopen, shlload, beos, and os2.
only linux and win32 were tested = i don't have access to any other
OS's.

> IMO, xmlsec and libxml2 are not about loading dynamic libraries.
> Thus, if there is a piece of code that can be re-used then I prefer
> to re-use it. With ltdl there is a clear maintanance path. If tomorrow
> there is a new platform XYZ that are supported by ltdl then current
> xmlsec code almost automaticaly gets it too. With custom code you have
> to write, debug and test new code on this new platform.

in general i agree - i'm not interested in reinventing the wheel. 
there are a few arguments though on the other side:

1) libxml2 seems to be a quite widely used library, and as such,
   adding new library dependencies is discouraged.
2) its about 50 lines per new platform, of which less than 10 do all 
   the real work - the rest are comments, variable declarations, etc.
3) ltdl's license is LGPL not MIT/BSD.
 
btw, my first crack at exslt:crypto used libltdl to dynamically load
the openssl crypto library so as to not add further dependencies
to libexslt. people seemed to be very concerned about symbol
conflicts if the patch was accepted using libltdl so eventually
i changed the patch to use gcrypt & no dynamic loading. 

i wonder if including basic DSO services in libxml2 is kind of
like including a fair bit of regexp code instead of using pcre or
some other regexp library...?

> In the long run, if dynamic libraries loading is added to libxml2 then
> I would love to convert xmlsec to use it (see main reason above - xmlsec
> is not about dynamic loading :) ). However, if the implementation would
> be based on custom code then I would prefer to wait until it is proven
> to work on all platforms supported by libxml2/xmlsec (the most important
> ones are: linux, winnt, solaris, aix, mac, beos, hp-unix).

i completely agree that if we go with my patch, we should nail
down all the important platforms before xmlsec would switch.

> Regarding API (looking at the patch in Joel's mail from 12/21/04):
> 1) What is the difference between xmlModuleClose and xmlModuleFree?

xmlModuleFree is used when you've loaded the DSO into memory 
& want to keep it in the process address space, but free libxml 
related module buffers. we could get rid of struct xmlModule.name and 
thereby alleviate the need for xmlModuleFree. i put it there to make 
debugging easier. xmlModuleClose is there for the load a module/DSO, 
use it, and close it use case. 

> 2) What about thread safety of these calls?

there are no globals, so only thread safety of platform specific
calls would be an issue, imho.

> 3) Do I need to specify full path in xmlModuleOpen call or just filename
> would be enough (e.g. is LD_LIBRARY_PATH supported or not)?

both full path and just filename are supported. just filename
is of course platform specific.

jr