Re: [xml] Re: The DSO dilemna

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]