httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: binary backwards compatability.
Date Wed, 29 Mar 2000 22:23:48 GMT
On Wed, 29 Mar 2000 rbb@apache.org wrote:

> Huh?  How does what I propose stifle innovation, or waste too much RAM?

you proposed adding unused space to the end of structures -- presumably
all structures.  that's wasted RAM.

requiring backwards compatibility wouldn't have let us fix various
protocol bugs or implement some performance upgrades... just read ap_mmn.h
and figure out how many of those you could have made binary compatible.

> It's not like I suggested keeping all of the old API's around forever.
> That was voted down a week or two ago.  I am simply suggested that we
> allow the module to be smarter about whether or not it is compatabile with
> a given version of Apache.
> 
> Currently, we check the MMN, and if they don't match, we give up.  The
> module knows more about itself than we do.  If a function has changed, but
> the module doesn't call that function, then the module is still binary
> compatable.

it's not about adding a new function.  that's easy to handle.

it's about updating semantics.

19981229, for example, affects any module doing negotiation.  your
proposal has no way for old modules to say "i do negotition and any
semantic change involving negotiation is something that will break me".  
it requires us to forecast what the semantic changes can be!

19981108 and 1990320 affected modules manipulating r->method...

this is an extremely hard problem.

binary backwards compatibility is responsible for such stupidities as the
Solaris 256 FILE * limitation -- they used a byte to represent the fd, and
they couldn't fix it.

just say no.

Dean


Mime
View raw message