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 Mon, 03 Apr 2000 10:28:36 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.

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


Greg Stein,

View raw message