Re: [xml] Re: The DSO dilemna

[Daniel Veillard <veillard redhat com>]

On Thu, Dec 30, 2004 at 01:23:41PM -0800, Aleksey Sanin wrote:
> Yes, I do export these functions but nobody is expected to use
> them directly anyway. I don't like breaking ABI and most likely
> I would have to write a dozen of stub functions to replace these
> xmlsec_ltdl_* ones (new functions would do nothing and always
> return an error).

  <grin/>

> BTW, this is another reason why I would have to think twice
> about this :)

  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.

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/