Re: [xslt] Extending EXSLT support to get the crypto part

[Bjorn Reese <breese mail1 stofanet dk>]

On Mon, 2004-05-10 at 20:41, Daniel Veillard wrote:

>   Unless serious concern being raised and once the configuration
> stuff is being sorted out, I think I will make that change, so if
> you have a strong feeling about this, please speak up :-)

I have no problem with this suggestion, but I believe that it should
be implemented with care. I believe that two requirements are necessary
for the implementation:

1. It shall work in the absense of third-party libraries.
2. It shall be possible to use other third-party libraries.

My favorite solution to these two requirements is provide an interface
that third-party libraries should adhere to; we control this interface.
Libexslt is then given an "object" (a struct, a collection of callback
functions, whatever) that adheres to this interface, and uses this
"object" instead of going directly to, say, OpenSSL. We cannot expect
third-party libraries to adhere to such an interface, so we need a
wrapper between our interface and the third-party library.

I have suggested this before e.g. for the multithread support, and I
still think that this is the best decoupling techniques. The
application, not libexslt (or other libraries), should decide what
threading or crypto model it wants to use. Forcing such decisions on
applications is a problem when two different libraries dictates two
different, and possibly incompatible, approaches. Although, libexslt
provides configuration options to disable certain features, this is
not always an acceptable solution if the application developer cannot
decide which features are present, or need different features in
different situation (e.g. for different applications built on the
same machine.)

The above applies to libxml and libxslt too.

One a completely different note, there are some licensing concerns
about mixing OpenSSL with GPL covered code. See:

  http://www.openssl.org/support/faq.html#LEGAL2