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 Thu, 30 Mar 2000 01:57:22 GMT
On Wed, 29 Mar 2000, Dean Gaudet wrote:
> so then 3rd party module writers would override the check, because they
> don't want to set up any infrastructure for "frequent" releases of their
> code, and folks using 3rd party modules will see odd segfaults and other
> bizarre happennings with their server.
> and folks supporting apache will have to find out the versions of all 3rd
> party modules in use, and have to guess if those modules are causing the
> bizarro behaviour the customer is reporting.

Agreed -- having to deal with binary modules is a pain in the ass. We
could also make it a policy to punt :-)

I'm +0 for the change, so don't mistake that I'm pushing for it... :-)

> > Consider the M_INVALID change: I could write a module today that
> > understands the current and old values, and compensates accordingly.
> how would it know about the new value?  this is a compile-time constant.

Not the *new* value. It would know today's value (which it was compiled
with), and it would know the old value (before we changed it).

Using various checks like this, a module could operate against 1.3.0 thru
1.3.12. It could also operate against later versions, unless/until we
changed the major version.

> > 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.
> how would you know about new API functions?  you're talking about
> predicting the future.

No, I'm talking about knowing the *past* changes.


Greg Stein,

View raw message