Re: [xml] Re: The DSO dilemna

[Daniel Veillard <veillard redhat com>]

On Thu, Dec 30, 2004 at 06:02:58PM -0500, Joel Reed wrote:
> 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:

  thanks Joel to put your suggestions forward !

> 1) xmlmodule.h would be roughly what it is now

  IMHO we should just add the flags options to xmlModuleOpen signature.
Even if we don't implement it right now, I think it makes sense though 
apparently ltdl.c doesn't allow to pass the options ...

> 2) xmlmodule.c would use libltdl DSO API to implement 
>    xmlModuleOpen, xmlModuleClose, etc.

  okay

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

  This is the most controversial point. It is clean in the sense that
if available on the platform we benefit from the update. But I'm afraid it
will be a mess on exotic platforms, and even on linux. For example right
now it's provided by libtool on my installation. But libtool is part of the
developpement environment not of the runtime platform. So if I ship libxml2
compiled that way, it will require to install libttool on target boxes which
should not have development tools. 

> does this work for everyone? (fingers crossed)

  We can make this a configuration flag or option, --with-sys-ldtl ...
which if activated will try to do what you suggest and if not found or
not activated will fallback to a locally modified copy. This is very
similar to the current approach taken for the trio library. Except I will
be very tempted to use the local copy even on Linux. The point being that
if for some reason we don't embed the latest version users still have the
option to use their version they know work for them in their specific
environment.
  I'm fine doing the mess of embedding the local copy and adding the special
configure option if you provide the configure lookup and the ldtl based version.
And if we can't pass the flags to xmlModuleOpen then too bad but it should
not stop us from trying that approach.

  What do you think ? I hope we are slowly converging :-)

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/