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 21:06:45 GMT
Paul Querna wrote:
> William A. Rowe, Jr. wrote:
>> 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.
> Yeah, we need to sketch out how the DSO loading works API wise, and do
> it in a generic way, such that most of the symbols exist in the main
> library, but at runtime we can pull in a bunch of libraries.
> For example, apr_ldap_open or apr_dbm_open should exist, but we
> shouldn't hard link to libldap or libdb46 instead perhaps have shim
> shared DSOs that we load, libapr-ldap.so, which are linked to them.  I
> think an approach like this could work on most Linux/BSD/OSX type
> places, but I'm sure it will have problems on some rarer unix OS.

We don't hard link to libdbXX anymore :)  Catch up with us here LOL.

The apr_ldap api should either be dumped or made a full abstraction,
it's a crufty design.

> But doing this is anotheer reason to do it in SCons, it would make all
> the dynamic/static libs compiling much easier.

Hmmm.  I'm far from convinced, you'll have to demonstrate a flaw in the
current schema to convince me :)

>>>                     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.
> Do we even need it at all?  Can't we just remove it and tell people to
> use IBM's ICU? (or another library?)

That's the point.  Maybe multiple interfaces from apr_xlate into icu
(I didn't see the mapping, but this is a version major bump so we might be
able to identify a common api) or libiconv.  Either way, this falls into the
dso binding strategy as well.

View raw message