Re: [xml] Re: The DSO dilemna

[Joel Reed <joelwreed comcast net>]

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

snip

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

joel