Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 3764 invoked by uid 500); 30 Mar 2000 01:52:26 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 3750 invoked from network); 30 Mar 2000 01:52:25 -0000 Date: Wed, 29 Mar 2000 17:57:22 -0800 (PST) From: Greg Stein To: new-httpd@apache.org Subject: RE: binary backwards compatability. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Wed, 29 Mar 2000, Dean Gaudet wrote: >... > so then 3rd party module writers would override the check, because they > don't want to set up any infrastructure for "frequent" releases of their > code, and folks using 3rd party modules will see odd segfaults and other > bizarre happennings with their server. > > and folks supporting apache will have to find out the versions of all 3rd > party modules in use, and have to guess if those modules are causing the > bizarro behaviour the customer is reporting. Agreed -- having to deal with binary modules is a pain in the ass. We could also make it a policy to punt :-) I'm +0 for the change, so don't mistake that I'm pushing for it... :-) > > Consider the M_INVALID change: I could write a module today that > > understands the current and old values, and compensates accordingly. > > how would it know about the new value? this is a compile-time constant. Not the *new* value. It would know today's value (which it was compiled with), and it would know the old value (before we changed it). Using various checks like this, a module could operate against 1.3.0 thru 1.3.12. It could also operate against later versions, unless/until we changed the major version. > > Likewise, I might have two code paths for dealing with different semantics > > of some API functions. Maybe my module dynamically looks up exported > > API functions, allowing dynamic use of certain functionality. > > how would you know about new API functions? you're talking about > predicting the future. No, I'm talking about knowing the *past* changes. Cheers, -g -- Greg Stein, http://www.lyra.org/