apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: On to APR 2.0.0? Beyond 9x/ME
Date Sat, 03 Jan 2009 20:06:54 GMT
Justin Erenkrantz wrote:
> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
> <wrowe@rowe-clan.net> wrote:
>> I don't know that we have any active interest in 2.0.0 at this moment,
> 
> Since I guess trunk is now 2.0.0, here's what I'd like to see:
> 
> 1. fold in apr-util

+1, with the dso approach, it is not so harmful for apps to link to it,
and it solves the mutex initialization problems reported by Joe.  If this
means apr-util/trunk disappears, that's fine.

>                     and apr-iconv into apr trunk.

-1; we need a different solution.  citrus, something based on the work of
the perl community (automated), or even IBM's ICU.  There isn't the long
term interest in maintaining this.

> 2. move to a SCons-build system (if you don't have Python available in
> 2009, your OS sucks)

Create a sandbox, demonstrate it.  Same goes for cmake fans.  Time for a
shootout to eliminate our current headaches.

> 3. make pools runtime-configurable whether they are just a thin
> malloc()/free() wrapper or do internal reuse

Interesting, looking forwards to patches :)

> I'm volunteering to do the grunt work for 1.  I think I know someone
> who might volunteer for #2 (*nudge*).  And, #3 shouldn't be terribly
> hard to accomplish as long as we keep the pool API the same.  If we
> want to tweak the pool API, then that's far more involved.
> 
> Thoughts?  -- justin

Yup, time to move forwards.

Mime
View raw message