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: Moving external lib independant code from apr-util to apr
Date Mon, 24 Oct 2005 19:32:46 GMT
Mladen Turk wrote:
> Garrett Rooney wrote:
>> If it isn't possible to do that, then I'd like to see the parts of APR
>> util that pull in large third party libraries moved into their own
>> library (libapr-ldap, libapr-dbm, etc), leaving libapr as just the
>> portability code, libapr-util as dependency free code built on top of
>> libapr, and a few other libraries that pull in the additional third
>> party dependencies.
> Right, but how that makes the difference over my proposal?
> For example, take a look at apr-util's function apr_date_parse_http.
> First of all the definition include file is apr_date.h,
> so IMHO if both the definition and implementation are
> moved to apr, from user point of view it will make no difference,
> except that the function would reside in the apr instead of apr-util.

True.  But that's specific to a group of applications - e.g. it serves
their 'utility', it isn't a generic function.

> apr-util right now is *not* what it states it is, platform
> independent utility lib, because of third-party dependencies.

Yes, apr-util has some significant issues.  Let's speak to those,
rather than bloat apr?

> Further more, right now, even in the apr itself there are lots of
> OS independent code like hash, tables, etc..., so there is no
> 'political' reason that would prevent such a move thought.

Much of that code is used internally by apr.  If the functions are -not-
used by apr, and are simply 'utility' functions, then perhaps those
should be moved -out- of apr, into apr-util.

> Of course like Bill said, something like that can only be considered
> for the 2.0 version, but in real life because one can not use the
> apr-util without apr, it will not make any difference even now.

Correct, apr-util deliberately presumes it's a utility library built upon
the apr portability library.  The issue is that apr should be minimalist,
and if folks don't mind bloat, and want all of our interesting utility
functions, they draw in apr-util.  That's the design.

APR should truly address only portability, and the minimal utility required
to implement APR itself.  APR-util are all the 'goodies'.


View raw message