Mladen Turk wrote:
> Hi all,
> 
> Since apr-util mostly contains third-party libraries
> wrappers, and some code completely independent of any
> platform, I propose that we move that independent code
> from apr-util to apr, and since the API itself won't
> change it will not bring any build problems for
> apr/apr-util based application.

Not build issues, in general, but it's a complete ABI break; this would
be an occurance of a 1.2.x -> 2.0.0 bump, certainly.

> IMHO the apr-util should become interface over the
> existing third-party libraries, like iconv, xml, db,
> dbm, ldap, etc...
> 
> Things like buckets, sting manipulation, hooks, date, and others
> stuff that is completely dependent only on the apr should be
> moved to the apr itself.

The original design was that apr should be application-neutral.  buckets,
hooks, RFC-date and parsing functions appeared application specific.

If you are trying to avoid 3rd party library dependencies on db, xml, ldap
and so on, perhaps we can make this code less fragile, or not require so
many bindings when that code is not referenced by an application?

You described a course of action, but didn't offer a motivation/justification
for such a major change.  Would you take 2 steps back and provide some examples
why the current arrangment is an issue?

Bill