Re: [xml] Re: The DSO dilemna

On Thu, Dec 30, 2004 at 04:44:43PM -0500, Daniel Veillard wrote:


  Usually making design decisions for libxml2 is not very hard,
but in this case this is harder. Very much like when we ended up
integrating trio for portability, except the case is not that easy.
I don't want to grow libxml2 into yet another framework. libxml2 
itself doesn't need library loading. Extensions for XSLT does. XMLsec
does too, but already use a given code base. But I certainly don't
want to export all the symbols from that library. if we embbed ltdl
I want to restrict the part exported to a subset. Ideally the subset
you export now looks like the minimal API I would like to export and
reuse on top of libxml2. In both case we need to minimize the API
and rename it if reusing ltdl. I just hope we can converge on the
subset. Then whether it's called xmlModulexyz or xmlsec_ltdl_ doesn't
matter much we can just call the same code base which is the important
effect I'm looking to achieve in putting this in libxml2. Otherwise
it's a futile platform exercise and we're better limit stuff within 
libexslt and not export any such API.

here's my preferred solution:

1) xmlmodule.h would be roughly what it is now
2) xmlmodule.c would use libltdl DSO API to implement 
   xmlModuleOpen, xmlModuleClose, etc.
3) we would not include ltdl.{c,h} with libxml2, not use awk scripts
   to hack the ltdl apis, etc. but would instead require libltdl
   to be installed if module support is enabled. if you want module
   support, libltdl must be installed.

does this work for everyone? (fingers crossed)


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