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 Thu, 30 Mar 2000 00:59:39 GMT
On Wed, 29 Mar 2000, Randy Terbush wrote:

> I don't think we are talking about a significant amount of RAM. RAM is
> cheap.

RAM is cheap, cache isn't.  it's going to depend on which structures
you're wasting RAM on.  i certainly saw improvements when i added
-DDYNAMIC_MODULE_LIMIT=0 in apache-1.3, and that was "just a little bit of
RAM".

> This is a common practice to avoid the issues we are facing.

examples?

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

i gave an example already: what if a module was using M_INVALID, it
would be broken if we tried to use it without a recompile across the
19981108 change.

> We're not talking about, nor has the group ever advocated, maintaining
> brokeness. Just the module API interface.

they go hand in hand.  consider 19980312 and the change to all lower case
const strings (which was a performance improvement).

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

this is why we created MODULE_MAGIC_NUMBER_MINOR.

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

it's impossible to get right!  you're claiming that third-party module
vendors are going to be able to consult some oracle and say "yeah, i don't
need to be recompiled or changed in any way".  i'd like to have that
oracle, do you have some sample code?

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

what do you tell the binary module?

do you send it an english string "oh hi, please don't set the Content-Type
header in r->headers_out, please use the r->content_type header instead,
is that cool with you or should i error out now?"

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

apache is already widely accepted, so i'm having a hard time believing
your statements.

linux does not maintain binary compatibility, and it has wide acceptance,
and has a lot of 3rd party modules, and drivers.  go take a look at
how vmware works -- they provide source code for their kernel module
which communicates with a binary-only process that contains all their
proprietary code.  if you want to read more on the topic of binary
compatibility i suggest searching the linux-kernel archives
(www.kernelnotes.org).

here's an example of where binary compatibility screwed me in a previous
lifetime:  in order to get a particular product to market early and on
the meagre resources that i was assigned i had to hack apache in many
ways.  our sales group signed an ad sales contract (of course without
consulting engineering, this is how sales works) which required us to
link an auditing module with apache.  the auditing module was binary,
and was incompatible with the necessary changes i made to apache to
deliver the product.  the result:  A LOT OF HAIR AND TEETH PULLING.

my changes eventually found their way into apache.  and the auditing
company was eventually convinced to turn their auditing stuff into a
binary library, and provide a lightweight source module to interface
with apache -- they agreed this was better in the end because it made
all their efforts with other webservers easier as well.  but it was me
that had to do all the convincing.

if the apache group sends a "binary modules are cool with us!" message to
3rd party developers then you're going to screw over yourselves some day.

if you want to state something like:

	during a minor release cycle (x.y.n -> x.y.n+1) we will attempt
	at *all* costs to maintain backwards binary compatibility

i'm all for it.  except i thought that was already the state of affairs.

i wouldn't have minded us going from 1.3 to 1.4 to ... for the changes
that affect binary compatibility.

Dean


Mime
View raw message