apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] LDAP extension to apr-util (take 2)
Date Mon, 13 Aug 2001 21:40:35 GMT
On Monday 13 August 2001 14:13, Justin Erenkrantz wrote:
> On Mon, Aug 13, 2001 at 03:59:08PM -0500, William A. Rowe, Jr. wrote:
> > apr-util should be stable right out the door ... is this ldap code likely
> > to evolve significantly over time?
>
> Probably not.  I doubt there is much more work to be done for the LDAP
> code.  It is a fairly thin layer (although it isn't as thin as I'd like
> it, but that's me).
>
> As I see it, the problem is that if we add any features in httpd that
> require LDAP (mod_auth_ldap, httpd configuration via LDAP), you now
> need to check out apr-ldap.  Yuck.
>
> Based on the way Ryan tells it, apr-util should be the kitchen sink of
> things that don't belong in apr or in httpd.  I think we agree it
> doesn't belong in APR as it is not adding core portability features.
> I don't think it belongs in httpd as I could definitely use such code
> in other projects not associated with httpd.  apr-util seems the most
> logical place, IMHO.  -- justin

Actually, I have a real problem with apr-util too.  I don't want it to be the
kitchen sink of libraries, but that is what it was scoped to be.  I believe that
is a mistake.

The reason we scoped apr-util to be a kitchen sink, is that APR was adding
some stuff that wasn't strictly for portability.  I believe we would have found it
easier to not add everything if we had kept everything in one library.  Then,
we could have used the size of the library as justification for not including a
large component.

There are already multiple LDAP libraries, what are we trying to solve by putting
an abstraction layer into APR?  Are we sure that the problem needs to be solved,
or are we doing work just to do work?

Ryan

______________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message