httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randy Terbush" <ra...@covalent.net>
Subject RE: binary backwards compatability.
Date Wed, 29 Mar 2000 23:29:10 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.

I don't think we are talking about a significant amount of RAM. RAM is
cheap. This is a common practice to avoid the issues we are facing.

>
> 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.

Binary module compatibility should not effect these issues. We're not
talking about, nor has the group ever advocated, maintaining brokeness. Just
the module API interface.

>
> > 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.

But it has been treated as a fatal problem in the past. That is not easy to
handle from a module's viewpoint.

>
> 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!

We should not be concerned about the third-party module vendors level of
cluefulness. We just need to allow it. If we at least provide a method for
the older binary modules to decide their fate, we have accomplished our
goal.

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

Again, give the decision to the module vendor. Don't let the core decide
what is best.

>
> 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.

This is more of a major example that I would think as a group, we would
consider a major version number change for the server. There are limits to
what we can do. The above would be along the lines of expecting to run
binary 1.3 modules on 2.0. That is not what we are asking for.

Binary compatibility is important from the standpoint of giving third-party
modules vendors a stable module API to develop product for. Until we can do
that as a group, we will have limited success in getting Apache accepted in
some environments. We heard this several times from users at ApacheCon
wanting more third-party module support. This feature would be a good thing
for Apache's domination plans. :-)

>
> just say no.

We could do this by making it runtime configurable.


>
> Dean
>


Mime
View raw message