From dev-return-19565-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Dec 05 01:13:35 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 67018 invoked from network); 5 Dec 2007 01:13:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Dec 2007 01:13:34 -0000 Received: (qmail 13299 invoked by uid 500); 5 Dec 2007 01:13:22 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 13260 invoked by uid 500); 5 Dec 2007 01:13:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 13249 invoked by uid 99); 5 Dec 2007 01:13:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2007 17:13:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of justin.erenkrantz@gmail.com designates 209.85.132.248 as permitted sender) Received: from [209.85.132.248] (HELO an-out-0708.google.com) (209.85.132.248) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Dec 2007 01:13:02 +0000 Received: by an-out-0708.google.com with SMTP id c23so895270anc for ; Tue, 04 Dec 2007 17:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=wLSmzUbBerd39kGIlYsuRAdXZcHLKS/aDp1/zIBh/X0=; b=Ld6HRWE1MCrqFzRwuB4ki0sA2hT4YaH+4CRKTHrbX/SwKytY5y1la93Cd2h2icpLY40LueK8cio0Jh+mxWW7LOfyT+l0V1rUFqXeOw98rT/W3VEDxEK6bJmeDAA8MAPzG7HgA+jJ2atariZXgcvaTP+mr3ZO+dT/jPdWr1+rONk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XKg+c/C6jumthpltiAUv1TKts0MGYzG5qmqlM4pTjhvqqx6WQMrcHVbozd4Twjfas6KKFJMdx12VBePpPVzjCMcdSxrwmCyh89iIJwlTmJBigxu2S8gvJLC63sseKuMaWkwpsL/ClZQpqrDcL7fjczBetbuNJyo4ONjoFHW+gOw= Received: by 10.151.11.17 with SMTP id o17mr460618ybi.1196817183618; Tue, 04 Dec 2007 17:13:03 -0800 (PST) Received: by 10.150.144.10 with HTTP; Tue, 4 Dec 2007 17:13:03 -0800 (PST) Message-ID: <5c902b9e0712041713p287c64dey7f81c87f953f6ac6@mail.gmail.com> Date: Tue, 4 Dec 2007 17:13:03 -0800 From: "Justin Erenkrantz" Sender: justin.erenkrantz@gmail.com To: dev@apr.apache.org Subject: Re: APR 2.0 proposals In-Reply-To: <20071123103706.GA4169@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071123103706.GA4169@redhat.com> X-Google-Sender-Auth: 7461752035254f4a X-Virus-Checked: Checked by ClamAV on apache.org On Nov 23, 2007 2:37 AM, Joe Orton wrote: > ** Key proposal: "one tree, multiple libraries" +1. > ** Second (more controversial/radical?) proposal: > > Reduce the consolidated libapr library size by chucking out everything > from apr-util which has been around for N years and is not used outside > httpd. Anything that is used only by httpd should be moved to the httpd > tree, no point everyone else being burdened by it. Also chuck out stuff > which has *no* users at all. > > Impact: maybe gets rid of apr/random/, apr-util/buckets/, > apr-util/ldap/, half of apr-util/misc? (If/when httpd moves to the serf > buckets model maybe buckets can go away completely?) +1. There's enough feedback to see what most of our apps actually use and what's dead code or only used by httpd (hint: bucket brigades!). > ** Third proposal: > > Goes without saying: break API/ABI with wild abandon (ish). I know we've talked about it for a while: but what about punting pools or replacing it with a vtable impl? There's some nice code in APR that I'd like to use every once in a while, but importing the whole pool methodology gets a bit limiting. For example, Serf tries to primarily use an allocator scheme, but has to be tied to pools for certain calls back into APR. I shudder to think at what it'd be to actually implement such a split... =( -- justin