[EMAIL PROTECTED] wrote:
> I agree with you 100% adn I'm in the same boat. I suggest that if we
> can't get people on board that we just go our own way.
Whatever we come up with, I'm sure the classic OpenSSL API could
be layered on top of it. Perhaps we could consider this effort an
experimental refactoring of the OpenSSL codebase to improve its
quality and reusability.
> The problem is that at this point IMHO the product is designed to fit into
> a client model and only very restrictive server models. I think basically
> all we'll need to do is pull the crypto library and the protocol steps out
> of the code and rewrite the protocol in a state engine where we simply
> keep track of the progress of each connection.
Agreed. I was under the impression that their existing state machine might
be up to the task, though.
> The biggest difficulty I think will be understanding the present
> architecture of the project. I've looked inside and what I saw were reams
> and reams of code with no internal documentation to speak of.
That was my impression, too. I suggest we try to understand the existing
OpenSSL state machine, and come up with the tiniest possible bit of
code that puts the 'right' kind of interface on the existing functionality.
(Any bigger rewrite, and we'd never finish, I fear.)
After we've gone down that path a ways, we might decide it's easier
to rewrite parts of it from scratch, but let's put that off at least
until we know what we're doing :-)
- Dan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
