httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 12388] New: - Binary incompatibilities for modules developed with different builds of Apache v2.
Date Sat, 07 Sep 2002 13:23:27 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12388>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12388

Binary incompatibilities for modules developed with different builds of Apache v2.

           Summary: Binary incompatibilities for modules developed with
                    different builds of Apache v2.
           Product: Apache httpd-2.0
           Version: 2.0.40
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Other Modules
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: cm@cmunt.demon.co.uk


Hi,

This is not, strictly speaking, a bug but is, nevertheless, an issue that is 
quite a headache for vendors of pre-built modules for the Apache server.

I work with a database vendor - InterSystems, the authors of the Caché database 
and programming environment.  We offer two connectivity solutions for Apache 
users - CGI-based and module-based.  The later is distributed as UNIX shared 
objects and Windows DLLs.  The module-based solution working to the Apache API 
is obviously superior to the CGI- based solution in that it offers better 
performance.  However, because of the number of major revisions of the API (as 
defined by 'MODULE_MAGIC_NUMBER_MAJOR' in ap_mmn.h) we're finding it difficult 
to support this option.  We can accept and cope with having to release new
binaries for major version upgrades (e.g. Apache 1.3 to 2.0), but it's hard to 
keep up with incompatibilities that arise between different releases of v2.0.  
I'm sure this issue must be a problem for others too.

Would it be possible to build-in enough redundancy and further abstract the API 
such that it can be enhanced without disturbing the core functionality ?  
Obviously if one makes use of an API feature in a given release that isn't 
available for previous builds of Apache then an incompatibility will be the 
result, but it would be great if the basics remained compatible between upgrades 
- in much the same way as happens with the ISAPI and NSAPI interfaces.

Anyway, thanks for reading this.

Regards,

Chris.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message