Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Cc: APR Developer List <dev@apr.apache.org>
Message-Id: <BF60D7F5-8167-437B-9C58-6CCB07A39101@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: Greg Stein <gstein@gmail.com>
In-Reply-To: <BANLkTi=2oYi1Aat_GvTCeOmHH4SQW7nU-Q@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Proposal: splitting APR and former apr-util libraries
Date: Thu, 2 Jun 2011 13:51:07 +0200
References: <2C7D20CB-DBBA-4BBC-9EDA-55EF8B29B47D@sharp.fm>
 <BANLkTi=2oYi1Aat_GvTCeOmHH4SQW7nU-Q@mail.gmail.com>

On 02 Jun 2011, at 1:27 AM, Greg Stein wrote:

> You're just talking about bringing back apr-util.

Pretty much, without the "lump it all together in apr-util".

> Making these N different packages doesn't do much beyond just what the
> old apr-util did. I guess it solves a bit of dependency stuff.

I disagree, it goes a lot further - it solves the problem of what to  
do if an API is proposed for APR that is simply too big for the library.

At this point we have no "escape valve" to protect us against code  
bloat. Our only option at the moment is to keep adding stuff to the  
core apr project, or just rejecting code with the explanation "we're  
full, go away". Neither of these are healthy options.

> Personally, I gave up on the "combined vs split" argument a long time
> ago. This community wanted to combine everything, and I felt
> differently. It happens. I also felt that APR has got a lot of old,
> clunky code that needs to be cleaned up. As a result, I started my
> PoCore project to deal with just the low-level portability concerns,
> with a full revisit of all the concepts based on experience with APR,
> HTTPD, svn, and serf. High-level stuff can be left to applications or
> other third-party libraries.

If people are starting their own portability libraries, then it shows  
that apr is not fit for purpose in its current form, and that needs to  
be addressed by the apr project. I don't recall much discussion  
happening over "combined vs split", suddenly we were combined, and as  
I recall nobody provided an explanation as to what problem they were  
trying to solve by doing so.

It seems what we're working towards is combining apr and apr-util,  
removing most of the stuff that was in apr-util, ending up pretty much  
back with apr, which leads me to ask why we ever bothered combining  
the two in the first place.

Regards,
Graham
--