Daniel Hartwig <mand...@gmail.com> skribis: > On 5 February 2013 23:48, Ludovic Courtès <l...@gnu.org> wrote: >>> The gcrypt-guile project is doing so, I'll help it if I can. >>> But my original thought is orthogonal with gcrypt-guile, just put some >>> common digest algorithm in libguile rather than a full-stack crypto-lib. >> >> We could actually use the Gnulib crypto modules. There’s a >> duplication/convenience trade-off: we’d provide useful functionality by >> default, at the expense of duplicating C code in our tarballs (2500 SLOC >> for Gnulib’s sha*.[ch] and md5.[ch].) >> >> Opinions? > > Avoiding duplication and feature creep /in the core/ is highly > desirable. Guildhall makes it convenient enough to pull in additional > features; guile-lib has md5 and industria provides also sha and > others.
Scheme implementations of these would be impractical in many cases (too slow). > A small core with addons has some obvious benefits, for the platform. > Maintainers may disagree, though I notice that historic choices to > include some modules (such as sxml, web) in the core were made before > the advent of Guildhall. I wonder where these modules would reside if > they were introduced in the current situation …? Some modules were deliberately moved from guile-lib to Guile to improve integration, and to come with more standard APIs by default. I’m not sure that having guildhall changes much in that respect. >> I think I’d be more inclined to have good bindings in libgcrypt proper, > > Yes, this solution will have many benefits. The currently available > bindings are, well, not so great. However, the API is small enough > that building a proper set will not take much effort. Yeah, apparently there are several half-baked bindings around. Let’s just polish one of them, and submit it for inclusion in libgcrypt. Ludo’.
