apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Tue, 31 May 2011 18:13:19 GMT
On 31 May 2011, at 4:34 PM, William A. Rowe Jr. wrote:

> There are no plans for it because there are not three maintainers.   
> I am
> sweeping it to httpd trunk (with ap_ldap prefixes) almost entirely  
> intact,
> where there are some mod_authnz_ldap committers/fans.

Can you point out for me the thread on the dev@httpd list when this  
was decided? Why are we discussing changes to httpd on the dev@apr list?

> SVN is a history management schema, so it's easily retrieved by  
> willing
> developers, but the API is sufficiently broken that we are very  
> unlikely
> to see an acceptable resurrection proposal, as we haven't seen one in
> the past six years.

We have already agreed that any LDAP abstraction library needs to  
encapsulate the whole API like apr_dbd does, and that each LDAP  
implementation needs to be a discrete provider, just like apr_dbd  
does. And now you're telling us that no proposal has ever been  
discussed in the last six years?

And why the sudden urgency? Is there an APR v2.0 release imminent that  
you plan but haven't discussed with the list? And is this proposed  
release of APR v2.0 so important that others must stop what they're  
doing on httpd v2.4, followed by apr-util v1.4, to work on apr v2.0  
suddenly out of the blue?

Could the lack of interest in overhauling the LDAP interface be  
because the only person really interested in the overhaul is you,  
which leads me to ask why you haven't started working on the new API  
yourself? Your proposed apr_crypto.h file, when it finally was posted,  
was enormously helpful, despite the fact that much of the work you  
proposed had already been done on trunk and you weren't working from  
trunk for whatever reason. That kind of contribution can be built on  
and fosters collaboration. Ripping out code doesn't.

> If there are fans of httpd ldap interested in multiple ldap providers,
> the right answer would be mod_ldap_openldap.so, mod_ldap_netscape.so  
> etc,
> not ap_ldap.so stubs.  All would follow mod_ldap semantics, and there
> would be no need to load multiple mod_ldap's at a time (it could  
> even be
> clever and detect any siblings loaded, and barf intelligibly).

This is an awful idea, and I'd -1 it if we tried. We already have a  
well established pattern in the apr_dbd abstraction, which gives rise  
to modules like mod_authn_dbd, mod_authz_dbd, mod_session_dbd.  
Attempting to create a completely different pattern for LDAP support  
is significantly more ugly than the API we have now.

> So no, after wasting a week on untangling this mess, I don't see a  
> point
> to create new dead branches.

I do, so I will. APR exists to serve end users, and they deserve to be  


View raw message