apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: dyanmic loading revisited
Date Wed, 14 Feb 2007 21:26:24 GMT
William A. Rowe, Jr. wrote:
> david reid wrote:
>> I've been contemplating some pieces of functionality for apr-util, but
>> run into the whole "it's a kitchen sink" thing again. We've discussed a
>> few times having apr-util modules dynamically loaded and I think it
>> might be time to look at making this a reality.
> +1 - some thoughts...
> I don't have an issue with statically linking the stubs for the
> libraries used to the
> applications which want to consume them, and moving everything into APR
> (dumping apr-util), provided there is no dynamic linkage from APR itself
> into
> the unnecessary libraries.  No libldap/liblber binding to those .so's
> for an app
> or lib that isn't trying to speak ldap, etc etc.
> As long as apr itself has few 'hard' dependencies (lib not found moving from
> box to box, entry point not found on a slightly older client lib), I
> don't see any
> further win to continue the split between apr and apr-util.

Actually, thinking more about this idea, I think we should try and draw
up a list of the functionality that *should* be in the core of apr, and
then move everything else into modules that are loaded on an "as
desired/needed" model. Of course this could make things really complex :-)

I guess for me the set of "core" services would encompass stuff that
almost every module would require and would likely be smaller than the
current apr feature set. I would like to add some things though - so
maybe it would balance out ;-)

Does anyone else think this is taking things too far or is it worth
looking at?

> If we want it truly dynamic that's possible too.  I'm thinking of
> something more
> sip-like, more like what you get in perl or python consuming external libs.
> (I'd list PHP except for how often folks just roll that whole campground
> into
> a single sleeping bag of one library including extensions.)
> Finally I don't want 'two options' - we don't want a redhat, for
> example, to ship
> apr with fixed support for the openldap/openssl/mysql they ship, and
> then to find
> that you can't use a postgres client without rebuilding the whole damned
> library.
> Let's make it flexible enough that packagers/distributors can't box
> their way into
> a corner?
> Bill



View raw message