I suggest relating to OpenSSL as only one among the unlimited zillions of protocols out there,

and that by this reason, including OpenSSL support in Gambit is not the solution, but rather, to update Gambit's IO system to support implementation of non-leaky extremely-high-performance application/user-level ports.

Next in line are various compression and crypto protocols.


2013/12/18 Marc Feeley <feeley@iro.umontreal.ca>
There is no builtin support for SSL.  I have considered implementing this with OpenSSL or PolarSSL (which has the advantage of being lightweight and portable, see https://polarssl.org), but
 
it is a non trivial job due to the complex API required for SSL.

Yes. Also because OpenSSL is maintained by only one guy who gives part time to it, and its code is extremely bloated from its development process (this is what the experts on #crypto say anyhow).


Protocols and their support libraries are a complete jungle - for instance; I personally gave approximately one man month to implement an OpenSSL channel wrapper in Gambit. The whimsical documentation was on several key points indicative at best and inspiration from others' user code was required. The result is a very good integration, however at the same time,

Factors like this put an upper ceiling on what quality is actually possible to achieve for a particular integration/wrapper implementation, and this in turn means there will always be situations when a particular implementation is subqualitative and "in the way" and there is a palpable use of using some-other implementation, for someone to make his own new one, and so on.

 Moreover, this would add an external library dependency for Gambit (the only one), which is a problem for portability, so a configure option would likely be added to disable SSL support.

If someone wants to tackle this (i.e. implementing builtin support for SSL), I can help with the integration with Gambit's I/O system.  It would sure be nice to be able to open secure connections with Gambit.

Marc


I've pondered a bit how such an application/user-level ports interface would look.

To start with, a key decision would be if there should be support for something like zerocopying IO, i.e. you have a sandwhich of a number of such ports atop of each other and one or many of them is doing passive passthrough/forwarding only for N bytes/chars/seconds - will the IO system support that.

Perhaps that could be easily implemented if there's a convention that on such use, the user must not mutate the structures fed into the IO system any more.

This kind of design decisions could take a titanic-kind of direction though if carefully made and thought through it could be enormously useful also;

any code and modules relating to data streams, IO, and also data processing more generally, do at some point end up benefitting of having a qualitative interface with Gambit's IO system, through such an application/user-level ports interface.


I would be glad to participate in a conversation on the topic on how such a application/user-level ports interface ought to look more specifically.

Mikael