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
respected.
Regards,
Graham
--
