William A. Rowe, Jr. wrote: > david reid wrote: >> William A. Rowe, Jr. wrote: >> >>> >>> I'm doing some similar work, not for sockets, but to scratch apr's >>> implementation of hashing, etc from the library. Your ssl detection >>> looks >>> great, I'd much rather see this layer in apr-util (and perhaps a >>> apr-helper >>> lib of it's own) rather than apr core. It happens to be the same >>> place my >>> ssl detection code lives. I'm working on mine for FIPS-140 work. >> >> why not in core? > > Three thoughts. One, ssl is more of a library election than a platform > election > and apr is devoid of nasty ugly extra dependencies ;-) Two, it's a richer > interface; yes we might make core changes if we want 'pluggable > apr_io_read / write' but that doesn't mean the rich interface to ssl, or > other pseudo-io > interfaces has to live there. > > The third thought is that we already put crypto'ish stuff in apr-util.
OK My initial thoughts are that we should develop a firm patch for adding ssl library detection and setting of suitable defines for their use and get that into trunk - even if we're not yet using it :-) While the autoconf stuff should be easy and straightforward, in practise it rarely is and it's a decent stepping stone on the way. As per my work, I think we need a flag to say whether we have an ssl library (or ssl functionality in the windows case) and then additional flags for the type of library we have. I'll check again on Friday, but heading off for a few days away from the intraweb :-) david
