httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <>
Subject Re: binary backwards compatability.
Date Sun, 02 Apr 2000 00:52:46 GMT
So how about something like ap_query_API_capability()? A module could
call this and get back a pointer to a structure that described what the
API & core can do, and all the major/minor numbers too. Then the module
could sift through the struct and decide for itself whether it should
try to run. The struct might just be version numbers and a bunch of
capability booleans. Only the ordering of the struct would have to be
maintained. Extensions would be supported by adding elements to the end
of the struct.

It's a lot looser and potentially cleaner than the brute force API
freeze approach. One would hope that 3rd party module developers would
actually test their modules, rather than just assuming they'd work with
a later version of the core. Calling a capability query would only be
done once, at init time for the module.

Or is this too simplistic an approach which is doomed to failure by some
unforseen sophistication?

Greg Stein wrote:
> On Wed, 29 Mar 2000, Dean Gaudet wrote:
> > ... lots o' stuff ...
> I gotta go with Dean, partially. Trying to maintain backwards compat is
> awfully difficult, and given the experiences with Linux, it is
> "acceptable" in an Open Source environment.
> However: I like Ryan's suggestion for an *optional* version checking
> function. If the function is not provided, then we use the current check.
> If the function does it exist, then it will be called IFF the module's
> major version is >= Apache's major version. The module can make allowances
> for running against *old* Apache servers (NOT newer ones!).
> Consider the M_INVALID change: I could write a module today that
> understands the current and old values, and compensates accordingly.
> Likewise, I might have two code paths for dealing with different semantics
> of some API functions. Maybe my module dynamically looks up exported
> API functions, allowing dynamic use of certain functionality.
> I agree with Dean that a module should not be allowed to run *if* Apache
> is newer than the module (as defined by MAJOR); there is no way the module
> could know if its use of Apache has changed or not.
> [ I think that Dean was only looking in one direction of time... ]
Chuck Murcko
Topsail Group

View raw message