On Wed, Nov 10, 2004 at 10:38:23PM -0600, William Rowe wrote:
> It's the 80/20 solution, 80%+ of other modules never need to see
> the cruft, especially the cruft related to the underlying ssl
> library.
I don't think anything should be exposed by mod_ssl.h other than
optional function hooks to avoid creating tight coupling between modules
- that's one of 2.0's selling points. If you think more hooks are
needed, of course, that shouldn't be an issue.
> >> Aside from this, the solution is unlikely to be truly portable.
> >
> >It's a libtool flag and libtool either supports or ignores it.
>
> Compilers can't ignore the static fn() construct; they are always
> explicitly private. By far a better solution.
Making everything static would mean moving the entire module into a
single C file, I can't see how that's really viable.
> Could you describe what this patch accomplishes or was ment
> to accomplish?
It prevents global symbol table pollution (the use of {SSL,ssl}_* is
hardly unique to mod_ssl), it forces other modules to DTRT and use the
optional hooks rather than e.g. use ssl_var_lookup() directly, and it
makes function calls within mod_ssl fractionally faster: nothing that
blows you away but it's free for a single libtool flag.
Regards,
joe
