[cl-plus-ssl-devel] naming RAND_bytes wrapper

[David Lichteblau]

Quoting Anton Vodonosov (avodonosov at yandex.ru):
> The same will apply any other function we would want to export from cl+ssl.
> There will be a lower level FFI binding and a lispy counterpart.
[...]
> I am not sure what naming convention to use:
> 
>  (original -> FFI binding -> lispy version)
> 1. RAND_bytes -> rand-bytes -> rand-bytes-lispy
> 2. RAND_bytes -> cl+ssl-ffi:rand-bytes -> cl+ssl:rand-bytes (use separate package for the low level bindings) 
> 3. RAND_bytes -> rand-bytes -> random-bytes (i.e. for every new function make this decision every time, and joose some similar, but different name from the low-level bindind)

Just a couple of thoughts on this:

  - Such questions are hard to answer in full generality without
    looking at a full list of functions that would be exported.  How
    much more than RAND_bytes will there be?

  - Definitely (3) for this particular function. I don't care much which
    package the helper definition rand-bytes is in or how it's written
    (we didn't need a special package so far though, right?), but
    exported functions should have lispy names independent of C code,
    and RANDOM-BYTES is the perfect Lisp name for this function IMHO.

  - I think any exported API should be completely independent from the
    OpenSSL/Crypt APIs anyway.  Aside from overall lispiness
    requirements, the same API should feel natural when implementing it
    using, say, GnuTLS/libgcrypt instead of OpenSSL.  RANDOM-BYTES could
    be done using libcrypt's RAND_bytes or libcgrypt's gcry_random_bytes().

    (Whether anyone would actually implement a GnuTLS backend for CL+SSL
    is a different question; it wouldn't absurd though: The silly
    OpenSSL license alone might be reason enough; from a technical
    perspective it's also nice to have testing choices.)

  - Compatibility with Ironclad (for the features it offers; I
    don't think random-bytes in particular is included) might be nice to
    have.

d.