Return-Path: 
 <dev-return-34430-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 4369 invoked by uid 500); 1 Nov 2002 11:37:43 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
list-post: <mailto:dev@httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 4346 invoked from network); 1 Nov 2002 11:37:42 -0000
X-Authentication-Warning: kurgan.lyra.org: gstein set sender to
 gstein@lyra.org using -f
Date: Fri, 1 Nov 2002 03:38:48 -0800
From: Greg Stein <gstein@lyra.org>
To: dev@httpd.apache.org
Subject: Re: dav_new_error
Message-ID: <20021101033848.B29006@lyra.org>
References: <JLEGKKNELMHCJPNMOKHOMEBFHGAA.striker@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <JLEGKKNELMHCJPNMOKHOMEBFHGAA.striker@apache.org>;
 from striker@apache.org on Fri, Nov 01, 2002 at 10:42:09AM +0100
X-URL: http://www.lyra.org/greg/
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Fri, Nov 01, 2002 at 10:42:09AM +0100, Sander Striker wrote:
> Thought this might be something for you...
> 
> [08:56] <wrowe> hey folks, dav_new_error question for the svn'ers
> [08:57] <wrowe> anyone noticed the int save_errno = errno; bogosity within dav_new_error?
> [08:57] <wrowe> and has anyone suggested a good way to grab apr_status_t values into that dav_error rec?

It was a shortcut to avoid having to pass the darned thing to every call of
dav_new_error. The "right" answer is to add an apr_status_t to the param
list of dav_new_error.

Note, though, that adding a param to that function is technically an MMN
bump. However, there are only four Apache 2.0 mod_dav backends that I know
about (mod_dav_fs, mod_dav_svn, mod_dav_repos (Catacomb), and mod_dav_psql).
We can easily keep those up to date.

It would be nice to have a finer-grained MMN. In particular, one just for
the DAV API.

I've also been thinking that Justin's new ap_provider stuff should take an
ABI version number in there somewhere. A provider can register an API with a
particular ABI version. A user can ask for providers that match a specific
ABI. Or, (better) a user gets a provider and its ABI. The user can then
adjust its processing based on whatever ABI the provider was designed for.

Doing that to ap_provider would allow us to upgrade the provider-based APIs
without an MMN bump. With sufficient work, the user of a provider could call
the provider in N different ways, based on different incarnations of the
binary interface.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/