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

[joel reed <joelwreed comcast net>]

On Tue, May 11, 2004 at 07:42:29PM +0200, Bjorn Reese 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.

just a follow up note: i originally started this thread by posting an 
initial implementation that used OpenSSL, w/o runtime module loading,
without support for gnutls, etc. 

anyway, while i may still work on libexslt crypto:* sometime in the 
future, i no longer have an immediate need for the functions and 
felt the work required to do an acceptable solution (w/ runtime module 
loading, support for user-defined crypto lib, etc) was getting to high
for me in the short term.

jr

> 
> 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
> 
> 
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt gnome org
> http://mail.gnome.org/mailman/listinfo/xslt