[xml] The DSO dilemna
- From: Daniel Veillard <veillard redhat com>
- To: Aleksey Sanin <aleksey aleksey com>
- Cc: xml gnome org, "Kevin P. Fleming" <kpfleming starnetworks us>
- Subject: [xml] The DSO dilemna
- Date: Thu, 30 Dec 2004 05:01:48 -0500
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
I also looked quickly at GLib module support
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
- 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 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/
] [Thread Prev