Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 4233 invoked by uid 6000); 12 Aug 1998 17:36:28 -0000 Received: (qmail 4222 invoked from network); 12 Aug 1998 17:36:26 -0000 Received: from ns1.covalent.net (HELO zuul.covalent.net) (208.214.56.2) by taz.hyperreal.org with SMTP; 12 Aug 1998 17:36:26 -0000 Received: from montana.covalent.net (montana.covalent.net [207.91.27.101]) by zuul.covalent.net (8.8.8/8.8.7) with ESMTP id MAA14873 for ; Wed, 12 Aug 1998 12:36:24 -0500 (CDT) (envelope-from randy@Covalent.NET) Received: (from randy@localhost) by montana.covalent.net (8.8.8/8.8.7) id MAA10815; Wed, 12 Aug 1998 12:36:08 -0500 (CDT) (envelope-from randy) To: new-httpd@apache.org Subject: Re: [PATCH] friendlier MODULE_MAGIC_NUMBER checks References: <19980812160136.28135@deejai.mch.sni.de> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Randy Terbush Date: 12 Aug 1998 12:36:08 -0500 In-Reply-To: Martin Kraemer's message of "Wed, 12 Aug 1998 16:01:36 +0200" Message-ID: Lines: 39 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Diamond" Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Martin Kraemer writes: > I like the idea. I dislike (like Dean said, and like you say in the patch) > the duplication of mmn.txt in the comments. One of the two is okay, > but the other must go. I agree. Seems that it needs to be in the code. > If you create a ap_mmn.h perhaps, which consists of the mmn > change tracking and the defines, that file could be a possible > replacement for mmn.txt ... And it's easier to find the information > than if embedded in the bigger http_config.h I like that idea IF we include the macros for MODULE_MAGIC_NUMBER_* in the same .h file. Makes sense to me to have them in the same place. > What do the others think? > > Martin [sweating in hot munich. Hey! I'll go to the beergarden tonite!] Don't taunt me. :-) > On Sun, Aug 09, 1998 at 06:08:19PM -0500, Randy Terbush wrote: > > The following patch attempts to split out a _MAJOR/_MINOR numbering > > scheme. MMN_MINOR would mark the addition of new functions, etc. to > > the API. MMN_MAJOR would reflect structure changes, etc. that cause > > true incompatibility. I've also conditionalized the _MAJOR macro which > > could allow the ability to compile the server to match an older API > > interface if we were careful about wrapping structure changes in the > > _MAJOR macro that corresponds to it's change. Comments welcome. > > > > I've also pulled the mmn.txt into http_config.h. Makes more sense to > > me to have this distributed in the codebase. Sorry about the > > tabs. I'll commit an expanded version if this goes into Apache. > -- > | S I E M E N S | | Siemens Nixdorf > | ------------- | Voice: +49-89-636-46021 | Informationssysteme AG > | N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany > ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request