[xml] The DSO dilemna

[Daniel Veillard <veillard redhat com>]

On Fri, Dec 24, 2004 at 11:54:52PM -0800, Aleksey Sanin wrote:
> > 3/ libltdl seems to be under the LGPL licence, which is significantly
> >   different from MIT' one we are using
>
> From ltdl.[h|c] files in xmlsec distribution:
>
> > This library is free software; you can redistribute it and/or
> > modify it under the terms of the GNU Lesser General Public
> > License as published by the Free Software Foundation; either
> > version 2 of the License, or (at your option) any later version.
>
> > As a special exception to the GNU Lesser General Public License,
> > if you distribute this file as part of a program or library that
> > is built using GNU libtool, you may include it under the same
> > distribution terms that you use for the rest of that program.
>
> In my opinion, this exception permits ltdl redistribution in xmlsec
> package as it is done right now.

  Okay, now I'm faced with serious dilemna. What code base and API should
libxml2 use for dynamic loading of shared code. We have 2 code base:
    - Joel Reed proposal
    - ltdl.c
I also looked quickly at GLib module support 
http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html
and xmlmodule.h looks reduced set. Maybe we should inherit the loading flags
support (ability to do LAZY loading and local namespacing).

 Ideally the libraries based on libxml2 should be able to rely on the
API selected. XMLSec already relies on a modified ltdl.c, and Joel provided
the patch needed to get libexslt. 
 There is no Licence conflict
 - the ltdl code is bigger, has more cruft and will need to be modified
   but it is known to work
 - Joel's code is smaller, more in line with libxml2 code and apparently
   easier to maintain

 To me it looks like a tie, except Joel already put some significant effort
doing his patches. On the other hand the new API may not suit Aleksey's code
or changing to the new API may be considered too risky or not worth it.
 I have been thinking about this in the last week, but the only conclusion
I can get to is that it mostly depends on XMLSec reuse of libxml2 DSO API
(or not), whatever it is.
 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 ?
  - If yes then I think we should ship next version of libxml2 with Joel's
    DSO implementation.
  - if the API is not sufficient/too different, then we may have to adapt it
    or switch also to a modified version of ltdl code
  - If XMLSec's viewpoint is "if it ain't broken, don't fix it", a perfectly
    rationale viewpoint, then we should probably ship Joel's code too.

 So it mostly depends on how XMLSec may or may not evolve to reuse the DSO
API. I'm also more concerned by the API than by the implementation, it is
possible to retroffit (some of) the ldtl code to do the actual implementation
in case we face portability or stability problems.

  Opinions really welcome, I'm unable to make progress by myself on
this issue at this point.

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/