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: dyanmic loading revisited
Date Wed, 14 Feb 2007 19:03:25 GMT
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.

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


Mime
View raw message