apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Modular APR
Date Tue, 24 Mar 2009 17:19:41 GMT
Ruediger Pluem wrote:
> On 24.03.2009 17:41, Mladen Turk wrote:
>> Joe Orton wrote:
>>> On the topic of how to split up APR into multiple libraries, I had a
>>> look through the current directories, and a first cut at how I'd
>>> propose to split the code up would be:
>>>
>>>   (directory -> library-name [dependencies])
>>>
>>>   buckets -> libapr-buckets
>>>   crypto -> libapr-crypto
>>>   dbd -> libapr-db [libapr-buckets]
>>>   dbm -> libapr-db
>>>   ldap -> libapr-ldap (or, it disappears)
>>>   memcache -> libapr-memcache [libapr-buckets]
>>>   random -> libapr-crypto
>>>   xlate -> libapr-xlate
>>>   xml -> libapr-xml
>>>   util-misc/... ???
>>>
>> What's the technical reason for that?
>> With the merging of apr and apr-util I was hoping
>> we would have to care only on a single library
>> and now there will be dozen of them. Scary.
> 
> The most important thing is that we move out those parts which introduce
> dependencies on 3rd party libraries (well this requires a definition of 3rd
> party libraries, but this is another story :-)).
> So e.g. buckets might stay in the core library whereas dbd stuff at least the
> drivers move out into separate so's like today.
> Other examples might be xml or memcache.
> 

That's understood, and that's fine for any driver code
that depends on 3rd party lib.
Things like dbm should have libapr-dbm-berkeleldb
but not libapr-dbm. This should stay within the
core together with internal sdbm implementation.


Regards
-- 
^(TM)

Mime
View raw message