apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Proposal: splitting APR and former apr-util libraries
Date Thu, 02 Jun 2011 11:51:07 GMT
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.


View raw message