httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randy Terbush" <>
Subject RE: binary backwards compatability.
Date Mon, 03 Apr 2000 22:44:11 GMT

> On Thu, 30 Mar 2000, Randy Terbush wrote:
> >...
> > The goal is to allow the binary module vendors the ability to
> determine if
> > we can run on future versions of Apache. As it currently
> stands, a change
> > can be made to the server and the MMN can be changed which causes any
> > existing binary modules to fail to load. It is entirely
> possible that there
> > is no good reason for this and had the server not refused to
> run because of
> > an MMN mismatch, the binary module would still continue to work on that
> > newer Apache release. The module vendor knows whether it can safely run
> > based on the changes to the API and can make a decision whether
> to support
> > their module on the newer Apache, or do another release.
> While this is a nice ideal, I don't see that it can be reduced to practice
> in an effective fashion. It would create a tendency to freeze structures
> and APIs, rather than letting them Follow The Right And True Path.

If we were more consistant and disciplined about our use of MMN, I would
agree with you. But that has not been the case.

> > This is a simple problem that could nearly be solved if the
> server did not
> > have the final decision as to whether to run the binary module.
> Solving this
> > would go a long way toward convincing other companies doing add-ons for
> > Netscape, IIS, etc. to port their application to Apache.
> "Simple" problem?!! I don't think so. The module has to query information
> from the server to find out whether it changed in any way significant to
> the module. This implies a tremendous amount of reflection capability in
> the server. And a lot of maintenance to ensure that reflection code is
> always up to date.

I understand that the software solution is not simple. I think that we go a
lot further to solving the problem by giving the decision to the module
vendor/author.  That is simple. I also don't think code maintenance is a lot
more difficult than doing a proper job of keeping the .exp files current.

> Cheers,
> -g
> --
> Greg Stein,

View raw message