At 09:17 AM 2/5/2003, Jess M. Holle wrote:
>Graham Leggett wrote:
>
>>Greg Stein wrote:
>>
>>>Some questions for thought: if we start banging out versions right and left,
>>>then will people actually upgrade? Are we doomed to live with 1.3 forever?
>>>Or do we have to stick with today's architecture to support binary
>>>compatibility for N years?
>>
>>
>>I think OS distributions will play a large role in this. When the Solaris / Redhat /
>Suse / IBM / Whoever people start shipping v2.0 with their OS'es (which has already
>started happening in the case of redhat) adoption will be quite quick.
>>
>>In addition, apache v2.0 comes with SSL + LDAP built in, where v1.3 did not - this
>will probably give people more reason to use it.
>
>Built in only to a point. The standard distribution does not contain either of
>these. What's more, you have to rebuild the core (or APR at least) and link these in
>to have either of these.
>
>Sorry, but this hits a nerve -- with Apache 1.3 we had 2 major sets of potentially
>incompatible binaries - EAPI and non-EAPI. With Apache 2.0 we have 2 x 2 (=4), i.e.
>SSL and non-SSL enabled and LDAP and non-LDAP enabled and permutations thereof.
<fudbuster method="dispell">
Sorry but that's a pretty gross misstatement.
EAPI is an extension to the core server. It necessarily breaks binary
compatibility between modules (in a sometimes insignificant way - that's
for you - the module author - to determine for your module.) And you forgot
the third flavor, ApacheSSL, which also breaks compatibility. There is really
no reconciling a server built for SSL or without SSL with Apache 1.3.
With Apache 2.0, all of the hooks are there, all of the time. The core server
always remains compatible with all compiled modules, regardless of how that
core server was built (with or without SSL, with or without LDAP), with one
significant caviat. But SSL and LDAP have nothing to do with it, I have many
builds of mod_ssl alternately using OpenSSL and RSA's toolkit, and two LDAP
builds I'm working with, using both Netscape SDK and the Win32 API. The
point is I can load, or not load, any of those modules (although not two different
builds of the very same module.)
No, SSL and LDAP questions are FUD, that's for the RPM'er to determine.
(One caveat follows at the end.)
The real issue is how APR is built underneath Apache, and to a lesser degree
(because I consider the following a bug) how Apache made choices based on
APR's configuration. In other words, if APR is built without threading support,
you can't load a module that requires threading (even if Apache is running
prefork and the module does it's own thread pool magic.) If APR is built with
threading support, you can use prefork, worker or any other module. There are
some other more subtle distinctions in how APR is configured v.s. how it can
be used.
Those bugs, modules making choices based on APR build flags is usually
bad design. It's trivial to query the MPM to find out if the server is really using
multiple threads v.s. a single worker thread in each process. Testing the
APR_HAS_THREADS macro is usually the wrong choice for module authors.
But with good design, the author can ask APR if it supports or is using any
of a number of features at runtime, and can ask Apache what the profile of
the currently running MPM is (see mod_status and mod_info to get the
general idea.) And even across modules, optional functions allow one module
to publish functions that other modules may use (similar to EAPI, but much
more flexible and robust.) The best example here is mod_log_config, which
allows any module to add %{}n translations for a given character code.
The well designed module inquires of the optional function or registered
function, and if it can survive without finding that function, it should go
merrily on it's way without those specific features enabled.
So the simple fact is that with the 2.2 release we need to consider what
we advise module authors to code to ensure portability (and follow our own
advise), and we will finally eliminate the last vestiges of the EAPI problem.
</fudbuster>
>Is there any way we can stop linking LDAP and SSL into the core to use them, e.g.
>have mod_ssl be the only thing linking to OpenSSL and mod_ldap and/or mod_auth_ldap
>be the only modules linking to LDAP, i.e. so we can have one big mess of
>interchangeable binaries -- at least for a given MPM worker... [I have to believe
>this will settle down to worker for UNIX and the Windows worker for Windows for the
>90+% case for a while anyway.]
This is a bug in the way Apache autoconf's... OpenSSL and OpenLDAP should
never be linked to the core... they should have been detected and added only
to the modules/ssl and modules/ldap makefiles' CFLAGS/LDFLAGS.
Let's expect to fix that before releasing 2.2. And maybe consider always
enabling APR thread support while we are at it.
Bill
