Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 5496 invoked from network); 15 Jun 2004 09:50:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 15 Jun 2004 09:50:25 -0000 Received: (qmail 7158 invoked by uid 500); 15 Jun 2004 09:50:53 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 7068 invoked by uid 500); 15 Jun 2004 09:50:53 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 7042 invoked by uid 99); 15 Jun 2004 09:50:52 -0000 Date: Tue, 15 Jun 2004 11:50:08 +0200 From: Justin Erenkrantz To: David Reid , APR Dev List Subject: Re: [REVIEW] issues for 1.0 Message-ID: <39248842D970FCABB9C9D048@uio-8021x-153-0-25-58.uio.no> In-Reply-To: <02a401c4522a$cbbfb860$7500a8c0@goliath> References: <02a401c4522a$cbbfb860$7500a8c0@goliath> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.0.0-r10630 X-Spam-Checker-Version: SpamAssassin 3.0.0-r10630 (2004-05-13) on scotch.ics.uci.edu X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --On Monday, June 14, 2004 5:15 PM +0100 David Reid wrote: > - we need to decide if Ryan's proposed fix to the mutex_child_init should > stay or we stick with existing api. I've not been involved in it heavily, > BUT can we have some votes as otherwise I'll stick with what we have. My preference is to wait on this. I think making such a drastic change *right* before we go to 1.0 is asking for trouble. > - namespace protection in headers. Where do we stand on this? apr.hnw is > listed in STATUS? Realistically, I consider this a *yawn*. We could fix this up later, I think. > - thread return types. I see 2 +1's already for changing the type to an > apr_status_t. Anyone else care to comment/vote? I thought it wasn't portable to return a thread exit value on all OSes. But, sure, I guess it sounds reasonable. +1. > - version to apr_initialise. I see enough 3 +1's, but a -1 and a -0, so > comments? I think it's a good idea, but Greg with his -1 (veto) needs to chime in. > - apr_md5 functions. Should they change to void? Move to apr-util? MD5 already moved to apr-util. But, the return type is still apr_status_t. Yet, I don't see a particularly compelling reason to change this to void. *shrug* -- justin