On Fri, Oct 03, 2003 at 05:55:25PM +0100, Jill Ramonsky wrote: > It's worth summing up the design goals here, so nobody gets confused. > Trouble is, I haven't figured out what they should all be. The main > point of confusion/contention right now seem to be (1) should it be in C > or C++?, (2) should it support SSL or TLS or both?
If the applications have to interact with legacy systems, then they'd
need SSL...
> Regarding the choice of language, I think I would want this library (or
> toolkit, or whatever) to be somehow different from OpenSSL - otherwise
> what's the point? I mean ... this may be a dumb question, but ... if
> people want C, can they not use the existing OpenSSL? Or is it simply
> that OpenSSL is too complicated to use, so a "simpler than OpenSSL" C
> version is required. What I mean is, I don't want to duplicate effort.
> That seems dumb.
OpenSSL is very large, and although the API is pretty consistent and
easy to work with, the SSL part of it looks complicated anyway. Another
thing that is very annoying about OpenSSL is its license (and this has
probably been an incentive to create GnuTLS).
> My inclination is still to go with C++, and figure out
> a way of turning it into C later if necessary ... but if majority
> opinion says otherwise I'll reconsider.
Well as long as your library has a decent C interface, I wouldn't mind
if it was written in C, C++, Haskell or something even stranger.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
