[cl-plus-ssl-devel] adding support for libcrypto FFI

[Anton Vodonosov]

Hello Faré.

The original cl+ssl developers are not active in this mailing list.

I got myself commit rights when there were too many uncommitted
patches from users in the mailing list to help committing those patches.

Since then I do small maintenance like committing fixes people send
and updating the project page.

cl+ssl is declared as "A Common Lisp interface to OpenSSL.".
>From that point of view libcrypto bindings are appropriate
for cl+ssl.

Although currently cl+ssl is only limited to "wrap a stream into
SSL stream" functionality, I think I could commit the librypto
bindings.

As you see, cl+ssl is short of maintenance resources, therefore
the main question is will the new code increase maintenance
burden? Taking into account that OpenSSL API is quite stable,
I think new binding will not require significant maintenance
after they committed. And if there will be some new users
attracted by librypto bindings, it will increase the amount of
people who care about the library.

> what are you general
> guidelines (e.g. in terms of files and packages) to add such
> functionality to CL+SSL. (And if not, if you have hints on how to do
> it right or wrong.)

I am not aware about any guidelines. I have idea that if library 
has plain FFI bindings and a lispy interface on top of it,
then it's good to place FFI bindings into a separate package,
and the lispy inteface into it's own, separate package.

But that's not a strict requirement, just a wish. Current cl+ssl
code doesn't have this separation.

In general, I think it's not reasonable to place any barrier of
policies in front of you. Just send us the code you have,
and let's try to commit it as is.

In particular, I think it would be good to keep libcrypto bindings in a
separate package from the current cl+ssl code, so we can
just keep the package it is currently in.

There is already one libcrypto function exported by cl+ssl:
CL+SSL:RANDOM-BYTES. If your code has the same function
we may merge them, or just leave duplicated functions, if they
provide different lisp API.

Also we will need to document the libcrypto binding.
The minimal thing is putting two sentences on the library page:
"We also have libcrypto bindings in the package XXX. See the 
list of functions in lybcrypto-or-whatever.lisp and their
descriptions in the official OpenSSL documentation [link]".

That's all what I can think of.

Best regards,
- Anton