httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject RE: binary backwards compatability.
Date Mon, 03 Apr 2000 10:23:45 GMT
On Thu, 30 Mar 2000 wrote:
> > > But of course it can know... the module vendor has seen the source changes
> > > and knows if they can continue to release their version for the new Apache
> > > server version. As it stands, Apache decides for them.  Your making an
> > > assumption that the module has no knowledge of the changes in the server.
> > 
> > We're talking about binaries here. A given binary module definitely has no
> > knowledge about *future* changes in the server. Therefore, if the MAJOR
> > has been updated, then then binary module simply cannot run -- request_rec
> > may have been obsoleted for all it knows.
> You are correct, it cannot KNOW.  However, the module can make a damn good
> guess.  The module can look at what arguments are being passed to the
> functions it uses, and if they match up with what the module expects to
> see, that is a pretty good good indicator that the function hasn't broken
> the module.  The module could also check the size of the major structures
> (request_rec, server_rec, connection_rec), and get a good indication of
> whether it can still run.
> Is this perfect, no of course not.  But it is better than having the
> server say "If you weren't compiled for this exact version of the server,
> I don't support you"

It isn't perfect, but it can fail in spectacular ways. I just don't see a
reason to allow this kind of non-determinism. Gee? Will my module work?
Dunno. I'll just keep running it. Maybe it will work. Later, when they
find that it was failing to authenticate properly, they're going to be
pissed as hell.

I say we provide a hook that can say old major (and minor) versions are
allowed. But: if the module's compiled-in MAJOR is *less* than the one
Apache was compiled with, then it should bail.

Trying to create a mechanism to allow modules to execute on future
versions is prone to error and will be amazingly prone to feature creep.
I've heard about stabilizing APIs, only adding new APIs, feature 
capability sets and versioning, etc. Sheesh. With all that complexity,
we'll add more bugs than if we just made the vendor recompile their dang


Greg Stein,

View raw message