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 > -- david http://feathercast.org/
