Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 91553 invoked by uid 500); 23 May 2000 21:09:15 -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 91537 invoked from network); 23 May 2000 21:09:12 -0000 Date: Tue, 23 May 2000 17:09:39 -0400 Message-Id: <200005232109.RAA32664@k5.localdomain> X-Authentication-Warning: k5.localdomain: trawick set sender to trawickj@bellsouth.net using -f From: Jeff Trawick To: new-httpd@apache.org In-reply-to: <200005232057.QAA32577@k5.localdomain> (message from Jeff Trawick on Tue, 23 May 2000 16:57:33 -0400) Subject: Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open() Reply-to: trawickj@bellsouth.net References: <200005232057.QAA32577@k5.localdomain> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N A few minutes ago, I said > I would be curious as to when you would want to > allow new functionality to be added which would extend ap_xlateattr_t > if the type is not opaque. Would we have to wait for an APR version > number (major/minor/whatever) change? I get nervous when I have to be > clairvoyant in order to maintain binary compatibility. This seems pretty silly in retrospect... we don't have to do that, do we? At what point can we force apps to: 1) recompile if APR is dynamically loaded and they get a new copy (for Apache's benefit) which has an updated interface 2) modify source code in order to still compile with a new APR -- Jeff Trawick | trawick@ibm.net | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...