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

[Daniel Veillard <veillard redhat com>]

On Mon, May 10, 2004 at 04:42:02PM -0400, joel reed wrote:
> On Mon, May 10, 2004 at 09:11:14PM +0200, Igor Zlatkovic wrote:
> > On 10.05.2004 20:41, Daniel Veillard wrote:
> > 
> > > See bug #142105
> > >   http://bugzilla.gnome.org/show_bug.cgi?id=142105
> > >
> 
> snip
> 
> > ...Does it make sense to connect this to xmlsec? It is likely that, in 
> > practice, crypto extensions to XSLT will be used along with XMLSec. How 
> > realistic is the idea to call into libxmlsec from within libexslt to get 
> > crypto functionality, taking required modifications to both into account?
> 
> i'd be fine with reimplementing my patch above to use xmlsec, if there's
> some relatively easy way to generate MD5,SHA1, and RIPEMD160 sums with it.
> 
> i'd also be OK with the ltdl.{c,h} approach, though that sounds like more
> work ;)
> 
> it does sound like we(i)'d be eventually reimplementing alot of the xmlsec
> work with the ltdl.{c,h} approach, so maybe using xmlsec is smarter...

  Except you're generating a circular (nearly) dependancy
  xmlsec needs libxml2 and libxslt packages
so if we go the xmlsec route, it's better to use dynamic loading anyway
to keep sane dependancies and avoid cycles .....

> i don't suppose we want to just include BSD versions of SHA1,MD5, etc right
> in libexslt, but we could MD5 is about 300 lines of add once and forget about
> code, SHA1 is 700.

  Problem, is that creating new code in this area is a pain, because you
need to revalidate w.r.t. export regulation in the US. I would rather
not add any crypto code, just reuse existing libs.

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/