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. 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 …? > > 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. Curiously, some parts make use of S-expressions. Regards