I noticed a couple of these notes apply to me in one way or another so figured I'd chime in with some thoughts;
* Rodent of Unusual Size ([EMAIL PROTECTED]) wrote: > APACHE 2.1 STATUS: -*-text-*- [snip] > TODO ISSUES REMAINING IN MOD_SSL: > > * In order to use a DSO version of mod_ssl we have to link with > -lssl and -lcrypto. A workaround is in place right now where the > entire EXTRA_LIBS macro is being appended to the objects list, but > this is a hack. We should either revamp the APACHE_CHECK_SSL_TOOLKIT > autoconf function or come up with some other autoconf checks to > search for libssl and libcrypto and properly add them to mod_ssl's > link flags. I think the patch I sent to the list (which is awaiting comments BTW) will address this, but this is unconfirmed. Namely, my patch uses only LDFLAGS tweaks for library paths, and then only if --with-ssl=<path> is specified. For the remainder, autoconf's "normal" mechanisms for library probes and linker configuration are used. Ie. the actual probing for libssl and libcrypto is handled by the AC_CHECK_LIB() macro and so autoconf alone works out what flags are required from then on for linking apache. I'm wondering if the above problem is a consequence of us explicitly setting linker syntax and not letting autotools do their job properly? Anyway, the patch is there if someone wants to see if it helps with this issue as well. > * session cache store should be pluggable I'd like to speak with the person who's behind this, as I'm waiting for my current openssl-configuration changes to be reviewed and ironed out before I submit a new session cache module supporting 'distcache' (www.distcache.org). I'm also wondering if on the openssl-side we need some kind of modularised approach to session caching rather than this duplicating of effort in openssl-based apps. Unfortunately that would probably raise the issue that the basic session caching interface is inadequate and some rewiring would be required first. I see worms oozing out of cans. Anyway, I'm happy to discuss this issue with whoever is behind it in case I can be of any help. > * the shmcb code should just align its memory segment rather than > jumping through all the "safe" memcpy and memset hoops I wrote shmcb and I don't think the person who wrote this quite understands why this "jumping through hoops" is done. Trying to align all the relevant data will cost more than just a few wasted bytes of storage, and I respectfully suggest that the "safe" accessors (which aren't speed-critical) would be easier to maintain. Again, I'm available to bash these ideas out if anyone's interested. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
