You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Graham Leggett <mi...@sharp.fm> on 2011/05/30 21:48:27 UTC
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
On 29 May 2011, at 4:59 PM, wrowe@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1128885&view=rev
> Log:
> Begin refactoring to prepare for ldap removal
Would it be possible to make an apr-ldap-legacy branch before you do
this?
It would suck for end users if a body of code should suddenly
disappear, and there was nothing to point where it went or what the
future plans for it were.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by Guenter Knauf <fu...@apache.org>.
Am 02.06.2011 07:45, schrieb William A. Rowe Jr.:
> On 6/1/2011 12:35 PM, William A. Rowe Jr. wrote:
>> On 6/1/2011 7:11 AM, NormW wrote:
>>>
>>> Have httpd-trunk now building again for NetWare, but sent that diff to GK for his critical
>>> eye, as it took a bit more hacking for success.
>>
>> Sounds like a plan, committed the test fixes, thanks again!
>
> You know what, better idea; let's quell the failed build alerts please,
> go ahead and share what you have already and let's get that committed.
> This is trunk, it is commit-then-review :) When GK has cycles I'm sure
> he'll review this in his email box or from svn.
>
yep, will do.
Sorry for the autobuild noise - I've just stopped the builds until I
have time to split the build into apr and httpd.
Gün.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by NormW <no...@gknw.net>.
G/Evening...
On 2/06/2011 3:45 PM, William A. Rowe Jr. wrote:
> On 6/1/2011 12:35 PM, William A. Rowe Jr. wrote:
>> On 6/1/2011 7:11 AM, NormW wrote:
>>>
>>> Have httpd-trunk now building again for NetWare, but sent that diff to GK for his critical
>>> eye, as it took a bit more hacking for success.
>>
>> Sounds like a plan, committed the test fixes, thanks again!
>
> You know what, better idea; let's quell the failed build alerts please,
> go ahead and share what you have already and let's get that committed.
> This is trunk, it is commit-then-review :) When GK has cycles I'm sure
> he'll review this in his email box or from svn.
Hmmm. He _is_ busy of late; as long as no one barfs at him or me if
changed later.
Try this cluster then keep fingers crossed... :-) (me that is)
Index: modules/ldap/ap_ldap_rebind.c
===================================================================
--- modules/ldap/ap_ldap_rebind.c (revision 1130425)
+++ modules/ldap/ap_ldap_rebind.c (working copy)
@@ -42,14 +42,6 @@
};
typedef struct ap_ldap_rebind_entry ap_ldap_rebind_entry_t;
-
-#ifdef NETWARE
-#define get_apd \
- APP_DATA* apd = (APP_DATA*)get_app_data(gLibId); \
- ap_ldap_xref_lock = (apr_thread_mutex_t *)apd->gs_ldap_xref_lock; \
- xref_head = (ap_ldap_rebind_entry_t *)apd->gs_xref_head;
-#endif
-
#if APR_HAS_THREADS
static apr_thread_mutex_t *ap_ldap_xref_lock = NULL;
#endif
@@ -71,10 +63,6 @@
{
apr_status_t retcode = APR_SUCCESS;
-#ifdef NETWARE
- get_apd
-#endif
-
#if APR_HAS_THREADS
/* run after apr_thread_mutex_create cleanup */
apr_pool_cleanup_register(pool, &ap_ldap_xref_lock,
ap_ldap_pool_cleanup_set_null,
@@ -97,10 +85,6 @@
apr_status_t retcode = APR_SUCCESS;
ap_ldap_rebind_entry_t *new_xref;
-#ifdef NETWARE
- get_apd
-#endif
-
new_xref = (ap_ldap_rebind_entry_t *)apr_pcalloc(pool,
sizeof(ap_ldap_rebind_entry_t));
if (new_xref) {
new_xref->pool = pool;
@@ -152,10 +136,6 @@
ap_ldap_rebind_entry_t *tmp_xref, *prev = NULL;
apr_status_t retcode = 0;
-#ifdef NETWARE
- get_apd
-#endif
-
#if APR_HAS_THREADS
retcode = apr_thread_mutex_lock(ap_ldap_xref_lock);
if (retcode != APR_SUCCESS) {
@@ -206,10 +186,6 @@
{
ap_ldap_rebind_entry_t *tmp_xref, *match = NULL;
-#ifdef NETWARE
- get_apd
-#endif
-
#if APR_HAS_THREADS
apr_thread_mutex_lock(ap_ldap_xref_lock);
#endif
Index: modules/ldap/NWGNUmakefile
===================================================================
--- modules/ldap/NWGNUmakefile (revision 1130425)
+++ modules/ldap/NWGNUmakefile (working copy)
@@ -171,6 +171,10 @@
# Paths must all use the '/' character
#
FILES_nlm_objs = \
+ $(OBJDIR)/ap_ldap_init.o \
+ $(OBJDIR)/ap_ldap_option.o \
+ $(OBJDIR)/ap_ldap_url.o \
+ $(OBJDIR)/ap_ldap_rebind.o \
$(OBJDIR)/util_ldap.o \
$(OBJDIR)/util_ldap_cache.o \
$(OBJDIR)/util_ldap_cache_mgr.o \
Index: modules/aaa/NWGNUauthnzldap
===================================================================
--- modules/aaa/NWGNUauthnzldap (revision 1130425)
+++ modules/aaa/NWGNUauthnzldap (working copy)
@@ -189,6 +189,7 @@
aprlib \
libc \
lldapsdk \
+ utilldap \
$(EOLIST)
#
@@ -210,6 +211,7 @@
# Any additional imports go here
#
FILES_nlm_Ximports = \
+ ap_ldap_url_parse \
util_ldap_connection_find \
util_ldap_connection_close \
util_ldap_cache_checkuserid \
Index: include/ap_ldap.hnw
===================================================================
--- include/ap_ldap.hnw (revision 1130425)
+++ include/ap_ldap.hnw (working copy)
@@ -51,9 +51,6 @@
#define LDAP_DECLARE_DATA __declspec(dllimport)
#endif
-/* this will be defined if LDAP support was compiled into apr-util */
-#define AP_HAS_LDAP 1
-
/* identify the LDAP toolkit used */
#define AP_HAS_NETSCAPE_LDAPSDK 0
#define AP_HAS_SOLARIS_LDAPSDK 0
@@ -63,7 +60,26 @@
#define AP_HAS_MICROSOFT_LDAPSDK 0
#define AP_HAS_OTHER_LDAPSDK 0
+/*
+ * For ldap function calls that input a size limit on the number of
returned elements
+ * Some SDKs do not have the define for LDAP_DEFAULT_LIMIT (-1) or
LDAP_NO_LIMIT (0)
+ * LDAP_DEFAULT_LIMIT is preferred as it allows inheritance from
whatever the SDK
+ * or process is configured for.
+ */
+/* Novell SDK defines LDAP_DEFAULT_SIZELIMIT */
+#define LDAP_DEFAULT_LIMIT LDAP_DEFAULT_SIZELIMIT
+#ifdef LDAP_DEFAULT_LIMIT
+#define AP_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT
+#else
+#ifdef LDAP_NO_LIMIT
+#define AP_LDAP_SIZELIMIT LDAP_NO_LIMIT
+#endif
+#endif
+#ifndef AP_LDAP_SIZELIMIT
+#define AP_LDAP_SIZELIMIT 0 /* equivalent to LDAP_NO_LIMIT, and what
goes on the wire */
+#endif
+
/*
* Handle the case when LDAP is enabled
*/
Index: build/NWGNUenvironment.inc
===================================================================
--- build/NWGNUenvironment.inc (revision 1130425)
+++ build/NWGNUenvironment.inc (working copy)
@@ -304,7 +304,12 @@
endif
endif
-# Add support for building IPV6 alongside
+# Add LDAP protocol support
+ifneq "$(LDAPSDK)" ""
+DEFINES += -DAP_HAS_LDAP=1
+endif
+
+# Add IPV6 protocol support
ifneq "$(IPV6)" ""
DEFINES += -DNW_BUILD_IPV6
# INCDIRS := $(NOVELLLIBC)/include/winsock/IPV6;$(INCDIRS)
@@ -357,12 +362,12 @@
APRUTIL = $(subst \,/,$(APU_WORK))
APBUILD = $(SRC)/build
STDMOD = $(SRC)/modules
+LDAP = $(SRC)/modules/ldap
HTTPD = $(SRC)/modules/http
DAV = $(SRC)/modules/dav
NWOS = $(SRC)/os/netware
SERVER = $(SRC)/server
SUPMOD = $(SRC)/support
-APULDAP = $(APRUTIL)/ldap
XML = $(APRUTIL)/xml
APRTEST = $(APR)/test
PCRE = $(PCRESRC)
@@ -375,7 +380,6 @@
APRLIB = $(APR)/$(OBJDIR)/aprlib.lib
APRUTLIB = $(APRUTIL)/$(OBJDIR)/aprutil.lib
-APULDAPLIB = $(APULDAP)/$(OBJDIR)/apuldap.lib
STMODLIB = $(STDMOD)/$(OBJDIR)/stdmod.lib
PCRELIB = $(SRC)/$(OBJDIR)/pcre.lib
NWOSLIB = $(NWOS)/$(OBJDIR)/netware.lib
Index: build/make_nw_export.awk
===================================================================
--- build/make_nw_export.awk (revision 1130425)
+++ build/make_nw_export.awk (working copy)
@@ -29,8 +29,8 @@
#/ap_some_name/{next}
/ap_mpm_pod_/{next}
-/^[ \t]*(AP|DAV)([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)]([^ ]* )*[^(]+[(]/ {
- sub("[ \t]*(AP|DAV)([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)][ \t]*", "")
+/^[ \t]*(AP|DAV|LDAP)([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)]([^ ]*
)*[^(]+[(]/ {
+ sub("[ \t]*(AP|DAV|LDAP)([RU]|_CORE)?_DECLARE[^(]*[(][^)]*[)][
\t]*", "")
sub("[(].*", "")
sub("([^ ]* (^([ \t]*[(])))+", "")
add_symbol($0)
Index: build/NWGNUtail.inc
===================================================================
--- build/NWGNUtail.inc (revision 1130425)
+++ build/NWGNUtail.inc (working copy)
@@ -135,7 +135,7 @@
@echo $(DL)$(foreach incdir,$(strip $(subst
;,$(SPACE),$(INCDIRS))),-I$(incdir))$(DL)>> $@
endif
ifneq "$(strip $(DEFINES))" ""
- @echo $(DL)$(DEFINES)$(DL)>> $@
+ @echo $(DL)$(DEFINES)$(DL) >> $@
endif
ifneq "$(strip $(XDEFINES))" ""
@echo $(DL)$(XDEFINES)$(DL)>> $@
Index: build/NWGNUmakefile
===================================================================
--- build/NWGNUmakefile (revision 1130425)
+++ build/NWGNUmakefile (working copy)
@@ -18,6 +18,7 @@
FILES_prebuild_headers = \
$(SRC)/include/ap_config_layout.h \
+ $(SRC)/include/ap_ldap.h \
$(NWOS)/test_char.h \
$(PCRE)/config.h \
$(PCRE)/pcre.h \
@@ -44,7 +45,7 @@
@echo $(DL)-EP$(DL)>> $@
@echo $(DL)-nosyspath$(DL)>> $@
@echo $(DL)-w nocmdline$(DL)>> $@
- @echo $(DL)$(DEFINES)$(DL)>> $@
+ @echo $(DL)$(DEFINES)$(DL) >> $@
@echo $(DL)-I$(SRC)/include$(DL)>> $@
@echo $(DL)-I$(HTTPD)$(DL)>> $@
@echo $(DL)-I$(STDMOD)/aaa$(DL)>> $@
@@ -59,6 +60,10 @@
@echo Creating $@
$(call COPY,$<,$@)
+$(SRC)/include/ap_ldap.h: $(SRC)/include/ap_ldap.hnw
+ @echo Creating $@
+ $(call COPY,$<,$@)
+
$(PCRE)/%.h: $(PCRE)/%.h.generic
@echo Creating $@
$(call COPY,$<,$@)
HTH,
Norm
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/1/2011 12:35 PM, William A. Rowe Jr. wrote:
> On 6/1/2011 7:11 AM, NormW wrote:
>>
>> Have httpd-trunk now building again for NetWare, but sent that diff to GK for his critical
>> eye, as it took a bit more hacking for success.
>
> Sounds like a plan, committed the test fixes, thanks again!
You know what, better idea; let's quell the failed build alerts please,
go ahead and share what you have already and let's get that committed.
This is trunk, it is commit-then-review :) When GK has cycles I'm sure
he'll review this in his email box or from svn.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/1/2011 7:11 AM, NormW wrote:
>
> Have httpd-trunk now building again for NetWare, but sent that diff to GK for his critical
> eye, as it took a bit more hacking for success.
Sounds like a plan, committed the test fixes, thanks again!
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by NormW <no...@gknw.net>.
G/Evebing
On 1/06/2011 3:12 PM, William A. Rowe Jr. wrote:
> On 5/31/2011 9:04 PM, NormW wrote:
>> G/Morning
>>> I will have win32 repaired shortly. Some effort will be needed to have netware
>>> working again, but I will be updating the necessary .hnw files from apr while
>>> I handle the .hw files.
>>
>> if cleaning out apr-trunk ldap+NetWare, the following will help; getting httpd-trunk to
>> build for NetWare again is another (not so easy) story.
>
> Thanks Norm! Applied.
The diff was enough to get NetWare apr-trunk building; the 2 pieces
below are the last of NetWare related pieces (AFAICT).
Index: test/NWGNUaprtest
===================================================================
--- test/NWGNUaprtest (revision 1130033)
+++ test/NWGNUaprtest (working copy)
@@ -194,7 +194,6 @@
$(OBJDIR)/testhash.o \
$(OBJDIR)/testhooks.o \
$(OBJDIR)/testipsub.o \
- $(OBJDIR)/testldap.o \
$(OBJDIR)/testlfs.o \
$(OBJDIR)/testlfsabi.o \
$(OBJDIR)/testlfsabi32.o \
Index: build/NWGNUtail.inc
===================================================================
--- build/NWGNUtail.inc (revision 1130033)
+++ build/NWGNUtail.inc (working copy)
@@ -251,7 +251,6 @@
@echo $(DL)-sym internal$(DL)>> $@
endif
@echo $(DL)-l $(APR)/$(OBJDIR)$(DL)>> $@
- @echo $(DL)-l $(APRLDAP)/$(OBJDIR)$(DL)>> $@
@echo $(DL)-l $(APRXML)/$(OBJDIR)$(DL)>> $@
@echo $(DL)-l $(APR)/misc/netware$(DL)>> $@
@echo $(DL)-l $(APR)$(DL)>> $@
@@ -261,9 +260,6 @@
@echo $(DL)-l $(NOVELLLIBC)/include/winsock/IPV6$(DL)>> $@
endif
@echo $(DL)-l $(NOVELLLIBC)/imports$(DL)>> $@
-ifneq "$(LDAPSDK)" ""
- @echo $(DL)-l $(LDAPSDK)/imports$(DL)>> $@
-endif
@echo $(DL)-nodefaults$(DL)>> $@
@echo $(DL)-map $(OBJDIR)/$(NLM_NAME).map$(DL)>> $@
ifneq "$(strip $(XLFLAGS))" ""
Have httpd-trunk now building again for NetWare, but sent that diff to
GK for his critical eye, as it took a bit more hacking for success.
Cheers,
Norm
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/31/2011 9:04 PM, NormW wrote:
> G/Morning
>> I will have win32 repaired shortly. Some effort will be needed to have netware
>> working again, but I will be updating the necessary .hnw files from apr while
>> I handle the .hw files.
>
> if cleaning out apr-trunk ldap+NetWare, the following will help; getting httpd-trunk to
> build for NetWare again is another (not so easy) story.
Thanks Norm! Applied.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by NormW <no...@gknw.net>.
G/Morning
> I will have win32 repaired shortly. Some effort will be needed to have netware
> working again, but I will be updating the necessary .hnw files from apr while
> I handle the .hw files.
if cleaning out apr-trunk ldap+NetWare, the following will help; getting
httpd-trunk to build for NetWare again is another (not so easy) story.
Index: NWGNUmakefile
===================================================================
--- NWGNUmakefile (revision 1129913)
+++ NWGNUmakefile (working copy)
@@ -4,7 +4,6 @@
SUBDIRS = \
build \
- ldap \
xml \
$(EOLIST)
@@ -203,7 +202,6 @@
FILES_nlm_libs = \
$(PRELUDE) \
$(APRLIB) \
- $(APRLDAPLIB) \
$(APRXMLLIB) \
$(EOLIST)
@@ -229,14 +227,6 @@
$(EOLIST)
endif
-#If the LDAP support is defined then add the auto-load modules
-ifneq "$(LDAPSDK)" ""
-FILES_nlm_modules += \
- lldapsdk \
- lldapssl \
- $(EOLIST)
-endif
-
ifdef EXPATSDK
ifndef EXPAT_LINK_STATIC
FILES_nlm_modules += \
@@ -277,14 +267,6 @@
$(EOLIST)
endif
-#If the LDAP support is defined then add the imports
-ifneq "$(LDAPSDK)" ""
-FILES_nlm_Ximports += \
- @lldapsdk.imp \
- @lldapssl.imp \
- $(EOLIST)
-endif
-
ifdef EXPATSDK
ifndef EXPAT_LINK_STATIC
FILES_nlm_Ximports += \
Index: build/NWGNUenvironment.inc
===================================================================
--- build/NWGNUenvironment.inc (revision 1129913)
+++ build/NWGNUenvironment.inc (working copy)
@@ -42,13 +42,6 @@
$(error NOVELLLIBC does not point to a valid Novell LIBC SDK)
endif
-ifndef LDAPSDK
-LDAPSDK = C:/novell/ndk/cldapsdk/NetWare/libc
-endif
-ifneq "$(wildcard $(LDAPSDK)/inc/ldap.h)" "$(LDAPSDK)/inc/ldap.h"
-$(error LDAPSDK does not point to a valid Novell CLDAP SDK)
-endif
-
ifdef EXPATSDK
ifeq "$(wildcard $(EXPATSDK)/include/expat.h)"
"$(EXPATSDK)/include/expat.h"
EXPAT_IMP = $(EXPATSDK)/imports/expatlbc.imp
@@ -353,7 +346,6 @@
APR = $(subst \,/,$(APR_WORK))
APRBUILD = $(APR)/build
-APRLDAP = $(APR)/ldap
APRXML = $(APR)/xml
APRTEST = $(APR)/test
@@ -362,7 +354,6 @@
#
APRLIB = $(APR)/$(OBJDIR)/aprlib.lib
-APRLDAPLIB = $(APRLDAP)/$(OBJDIR)/ldap.lib
APRXMLLIB = $(APRXML)/$(OBJDIR)/xml.lib
#
Index: build/NWGNUmakefile
===================================================================
--- build/NWGNUmakefile (revision 1129913)
+++ build/NWGNUmakefile (working copy)
@@ -29,13 +29,11 @@
$(APR)/include/arch/netware \
$(APR)/include/arch/unix \
$(APRBUILD) \
- $(LDAPSDK)/inc \
$(EOLIST)
FILES_prebuild_headers = \
$(APR)/include/apr.h \
$(APR)/include/apu_want.h \
- $(APR)/include/apr_ldap.h \
$(APR)/include/private/apu_select_dbm.h \
$(EOLIST)
The ldap\NWGNUmakefile could also be removed if desired.
HTH,
Norm
PS Sorry No longer in apr dev list.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/31/2011 1:13 PM, Graham Leggett wrote:
> 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?
It was not discussed on the httpd list, this may be something of a surprise
to httpd. However, it would seem to be in our interests to be compatible with
APR 1.x and future APR 2.
I will have win32 repaired shortly. Some effort will be needed to have netware
working again, but I will be updating the necessary .hnw files from apr while
I handle the .hw files.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Jun 2011, at 12:53 AM, William A. Rowe Jr. wrote:
> Well, exactly. apr_crypto must be reviewed if anyone wants to ship it
> in 1.x, apr_ldap and apr_dbd probably don't change in generation 1.x
> (not unless there is some hugely compelling reason for backport).
jorton reviewed it first, and all of his requested changes have been
applied where they made sense. jimjag reviewed it a while back and
+1'd it as it stood. That's 3 (including me), just waiting for you to
make it 4.
> apr_dbd must be changed prior to apr 2.0 if there is anything we
> strongly
> believe must be corrected for GA. E.g. nothing can be dropped or
> changed
> from apr 2.1 (new functions, yes, deprecated, yes, changed, no,
> dropped, no).
>
> apr_ldap is new development, it doesn't need to change for apr 2.0.
> That
> is to say, a fresh apr_ldap can be introduced in apr 2.1 or 2.0. So
> it's
> just a matter of volunteer time, energy and momentum. In the
> interim it
> is where it belongs, at it's single consumer.
The only API I am worried about from a backport perspective is
apr_crypto in apr-util v1.4, as it's new. Everything else is apr v2.0
and onwards, as per our API rules.
> I am still waiting for your answer to who the other consumers are of
> apr_ldap.
No idea. For many years, we have been a general API that offered a
general portability library to any app that wants it, the days of us
being part of httpd are long gone. We set the standard for how APIs
should be managed, and that goes for all of our library.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4
build/apu-ldap.m4 configure.in
Posted by Bojan Smojver <bo...@rexursive.com>.
On Mon, 2011-06-06 at 17:53 -0500, William A. Rowe Jr. wrote:
> I am still waiting for your answer to who the other consumers are of
> apr_ldap.
I guess this will be hard to say. Do we track everyone that uses APR
APIs? Or did you mean just the open source projects out there?
--
Bojan
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/6/2011 5:30 PM, Graham Leggett wrote:
>
> Given that apr_crypto is in the
> soon-to-see-light-of-day apr-util v1.4, and we don't want to have APIs change
> unnecessarily, apr_crypto needs to be perfected first. That's some backports and some
> polishing away.
Well, exactly. apr_crypto must be reviewed if anyone wants to ship it
in 1.x, apr_ldap and apr_dbd probably don't change in generation 1.x
(not unless there is some hugely compelling reason for backport).
apr_dbd must be changed prior to apr 2.0 if there is anything we strongly
believe must be corrected for GA. E.g. nothing can be dropped or changed
from apr 2.1 (new functions, yes, deprecated, yes, changed, no, dropped, no).
apr_ldap is new development, it doesn't need to change for apr 2.0. That
is to say, a fresh apr_ldap can be introduced in apr 2.1 or 2.0. So it's
just a matter of volunteer time, energy and momentum. In the interim it
is where it belongs, at it's single consumer.
I am still waiting for your answer to who the other consumers are of apr_ldap.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Jun 2011, at 5:19 AM, William A. Rowe Jr. wrote:
> And I am confused with one thing. apr_crypto called out issues
> which cause
> apr_dbd arg lists to be reevaluated. However, that is not the
> complaint with
> apr_ldap, but I think you might be conflating them? If the arg
> lists to
> apr_ldap were an issue, I would have simply proposed the corrections.
apr_ldap has to be refactored, and the standardised part of the API
added, and the biggest risk to this effort is to do all the work, and
then discover that the API is wrong. This is exactly what happened
with apr_crypto. Time is an issue for me as well, I too have bursty
access to time, and once the momentum is going to have that momentum
killed is a big problem.
I believe at the very least, apr_crypto (because it's the newest),
apr_dbd (because it is the template of how we want modular APIs to
work), and apr_ldap (which will be the newest after apr_crypto is
done) should be up to the same consistent standard of API. (I also
believe that this should go further into other bits of apr that depend
on external libraries, but lets get these three nailed first). Given
that apr_crypto is in the soon-to-see-light-of-day apr-util v1.4, and
we don't want to have APIs change unnecessarily, apr_crypto needs to
be perfected first. That's some backports and some polishing away.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/03/2011 05:19 AM, William A. Rowe Jr. wrote:
> On 6/2/2011 5:51 PM, Graham Leggett wrote:
>> On 02 Jun 2011, at 4:19 PM, William A. Rowe Jr. wrote:
>>
>
> And I am confused with one thing. apr_crypto called out issues which cause
> apr_dbd arg lists to be reevaluated. However, that is not the complaint with
> apr_ldap, but I think you might be conflating them? If the arg lists to
> apr_ldap were an issue, I would have simply proposed the corrections.
>
> apr_ldap's issue is that it is an incomplete interface. It is useless
> without intimate knowledge and use of the system LDAP provider, per the
> standard ldap API. Therefore, whomever consumes apr_ldap must ***also***
> consume the system/toolkit ldap support, and that which apr was built
> against, to be specific.
>
>
I guess the point is that he wants to redesign the complete apr_ldap API to solve
the incompleteness issue. But he wants the API design to be correct in the first
shot. Hence he is waiting until apr_crypto and apr_dbd are in its final form
to have a blueprint for the new apr_ldap API to prevent the same "mistakes" with
this new API that were / are in apr_crypto / apr_dbd.
Regards
Rüdiger
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/2/2011 5:51 PM, Graham Leggett wrote:
> On 02 Jun 2011, at 4:19 PM, William A. Rowe Jr. wrote:
>
>> Graham, I am not, I repeat, not discussing your *contribution* to the ASF.
>> I respect the many, many things you have added, and aspects you improved,
>> and bugs you have fixed, which includes your patches to ldap.
>
> I have asked repeatedly for you to provide feedback on the apr_crypto APIs and to properly
> articulate your long standing objection, and you left both myself and the project waiting
> ages before you finally did so. I assumed the reason for this was that you were just busy.
> When you finally did provide feedback it turned out you had completely missed that fact
> that the a key part of your objection had been fixed on trunk 12 months earlier. I assumed
> your email was broken, or you had just missed that earlier patch to trunk, perhaps again
> because you were too busy, or perhaps it was a simple mistake.
Agreed, I had overlooked this. The reason for my delay is not the apr_crypto
API anymore, however. The apr_crypto API discussion drew my attention to other
API's which slipped in with some odd arglists that didn't follow the style of
the original library (particularly through the apr_util path). So I actually
have a library-wide review of all of our interfaces and a document to write
which spells out the style, particularly to C coders who might find the C++
style argument list conventions a bit unusual (**result as first arg of
constructors, *this as first arg of most methods, etc).
I can only do one bit at a time, be it fix win32 build for httpd against 2.0,
or fix ldap (which I believed was decided, see next), or figure out what 2.0
will do in the absence of apr-iconv (perhaps optional use of libiconv), or
whichever. And yes, I'm busy, so my contributions have been bursty and to
whatever is my largest itch at the moment, and last weekend it was to have
an entirely apr 2.0-ready httpd trunk flavor. apr_ldap was voted away twice
so I had no clue it would start a flamewar.
> In contrast, you didn't show me the courtesy of asking me for feedback on the state of
> apr_ldap code, to clarify whether there were any blockers, or whether there was anything
> you could do to speed things along. Instead you assumed I "couldn't be bothered" and
> declared as much on a public mailing list, after taking matters into your own hands
> ripping out the old code. In doing so, and despite your denial above, you have made your
> feelings on my contribution to the ASF quite clear.
That's only because when the issue was raised in 2010, there was no word that
future changes were in store. It was a pretty cut and dried answer from the
list, and you didn't respond. So I don't think I was out of line in just
assuming that there was nobody working on this code any longer.
> I am a member of the APR PMC, and a long standing member of the foundation, and this is
> because I care about the APR project, I care about other projects at the ASF, I care about
> the foundation, and I care about the end users and vendors who use our software. For this
> reason, I will continue the work on apr_crypto, followed by the work on apr_dbd, followed
> by apr_ldap, as agreed by this project in the past, until the agreed work is complete, no
> matter how unpleasant the task turns out to be. I however respectfully ask that you make
> this task no more unpleasant for me than it needs to be.
If we are blocking on you, or me, this isn't tenable. crypto is the first
because we have collectively studied this and want it done. dbd, or more
precisely the master list of exceptions, would be second, but don't feel
that you own responsibility to fix those. These are implementations which
don't suffer the incompleteness issues, but simply need arglist and naming
convention normalization. Those I'm going to chew on one API at a time,
but you and I are not the only two who could contribute to this.
The precise definition of how to fix apr_ldap (exporting all of the entry
points which a simple apr consumer would require) has been clarified years
ago and there is no effort towards this. If there are *3* committers to
support it, and more than one use case, the project would consider admitting
an implementation for apr 2.
In the interim, I'm reading your frustration, and your venting, but have not
read your response to the simple question... where are the consumers outside
of httpd mod_authnz_ldap? Jeff asks this question sincerely.
And I am confused with one thing. apr_crypto called out issues which cause
apr_dbd arg lists to be reevaluated. However, that is not the complaint with
apr_ldap, but I think you might be conflating them? If the arg lists to
apr_ldap were an issue, I would have simply proposed the corrections.
apr_ldap's issue is that it is an incomplete interface. It is useless
without intimate knowledge and use of the system LDAP provider, per the
standard ldap API. Therefore, whomever consumes apr_ldap must ***also***
consume the system/toolkit ldap support, and that which apr was built
against, to be specific.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Jun 2011, at 4:19 PM, William A. Rowe Jr. wrote:
> Graham, I am not, I repeat, not discussing your *contribution* to
> the ASF.
> I respect the many, many things you have added, and aspects you
> improved,
> and bugs you have fixed, which includes your patches to ldap.
I have asked repeatedly for you to provide feedback on the apr_crypto
APIs and to properly articulate your long standing objection, and you
left both myself and the project waiting ages before you finally did
so. I assumed the reason for this was that you were just busy. When
you finally did provide feedback it turned out you had completely
missed that fact that the a key part of your objection had been fixed
on trunk 12 months earlier. I assumed your email was broken, or you
had just missed that earlier patch to trunk, perhaps again because you
were too busy, or perhaps it was a simple mistake.
In contrast, you didn't show me the courtesy of asking me for feedback
on the state of apr_ldap code, to clarify whether there were any
blockers, or whether there was anything you could do to speed things
along. Instead you assumed I "couldn't be bothered" and declared as
much on a public mailing list, after taking matters into your own
hands ripping out the old code. In doing so, and despite your denial
above, you have made your feelings on my contribution to the ASF quite
clear.
I am a member of the APR PMC, and a long standing member of the
foundation, and this is because I care about the APR project, I care
about other projects at the ASF, I care about the foundation, and I
care about the end users and vendors who use our software. For this
reason, I will continue the work on apr_crypto, followed by the work
on apr_dbd, followed by apr_ldap, as agreed by this project in the
past, until the agreed work is complete, no matter how unpleasant the
task turns out to be. I however respectfully ask that you make this
task no more unpleasant for me than it needs to be.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/2/2011 6:10 AM, Graham Leggett wrote:
> On 02 Jun 2011, at 1:19 AM, William A. Rowe Jr. wrote:
>>
>> Justin had brought this to the list from a f2f hackathon for a decision as this
>> blocked 2.0 in 2009(!).
>
> "So, during the conversations we've had here in Amsterdam regarding combining APR and
> APR-util". Another example of discussions taken and decisions made off list.
Discussion != decision. There are discussions on mailing lists (this was),
there are discussions at f2f events, there are discussions with your coder
friends or coder colleagues that will inspire improvements in ASF code.
And amazingly, nobody at the ASF takes a vow of silence.
>> but you had years to set aside time, and couldn't be bothered.
>
> I am thoroughly disgusted by this remark.
Graham, I am not, I repeat, not discussing your *contribution* to the ASF.
I respect the many, many things you have added, and aspects you improved,
and bugs you have fixed, which includes your patches to ldap.
You note the code is not gone, it is at the home of its consumer; the only
consumer I know of. Please identify one more. Thanks.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Jun 2011, at 4:09 PM, Jeff Trawick wrote:
> What are the critical facts?
>
> LDAP support in APR 2.0:
>
> * there was [almost] no support for preserving the status quo; those
> that spoke up wanted either to make it a full API or drop it
> ** more wanted to drop it
> ** Graham offered to do the work to make it a full API
>
> * AFAIK we did not resolve the fact that more people spoke up for
> removal than for making it a full API ("tentative compromise"?)
>
> * nobody got around to either removing it or making it a full API for
> a long time afterwards, for the same multitude of reasons that other
> things do not get done
>
> * wrowe finally got around to take action, which was to yank it
> ** I dunno if that was preceded by a notice, which would have been
> "nice" (no, I haven't spent much time in my inbox :( )
>
> Any dispute so far?
Yes, you missed out the apr_crypto and apr_dbd API issues that blocked
apr_ldap.
apr_crypto was written off a direct template of the apr_dbd code under
the understanding that apr_dbd represented the accepted level of API
quality in apr. Feedback since the apr_crypto code was committed has
revealed that apr_dbd does not represent the accepted level of API
quality in apr, with respect to the passing of multiple context
pointers at the same time, and the ordering of the parameters, and it
has been made clear by those expressing their disapproval that this is
required to be fixed. I agree with them. As you are aware, fixing
apr_crypto is a top priority, because it blocks apr-util v1.4 and
httpd v2.4.
Given that the plan was to model the apr_ldap code on apr_dbd, work on
apr_ldap was suspended until the issues of exactly what was wrong with
the apr_crypto and apr_dbd APIs was resolved. Most specifically, the
plan was as follows:
1) apr_crypto gets all required changes made to it, people agree that
apr_crypto's interface represents the level of quality acceptable to
the project. Feedback on apr_crypto has been torturously slow, but it
has at last arrived.
2) apr_dbd gets the same changes applied to it to bring it to the new
standard required of apr_crypto, people agree that apr_dbd's interface
represents the level of quality acceptable to the project.
3) apr_ldap gets written from scratch, carefully ensuring as little
disruption for the 7 different toolkits we support (ie we leave the
autoconf stuff alone, as it already works, the API is a problem),
again with an interface consistent with apr_crypto/apr_dbd, and to the
level of quality acceptable to the project.
Where are we right now? We're still at step one above. Wrowe has after
a long delay provided an apr_crypto.h file that represents the
blueprint for what he believed was wrong with the apr_crypto and
apr_dbd APIs, and his issues have been recently fixed. These have been
backported to apr-util v1.5 and v1.4. Further polishing has taken
place, and these too need backporting, and I planned to have this
resolved this week while trying to have a holiday.
The work on apr_dbd was to happen next, but wrowe expressed his
preference to wait until httpd v2.4 was out the door (no objection
from my side). My plan was to propose a new apr_dbd API within the
comments of apr_dbd, giving people the opportunity to agree on the
changes in principle before they were applied in practice. I was not
prepared to start the work on apr_ldap until I had a solid and agreed
template on which to build upon, as I am not prepared to repeat the
torturous process of vague objection followed by endless delay that I
experienced writing apr_crypto. In the mean time, there is enough work
to keep me busy on httpd v2.4.
At this point, out of the blue, something snaps and wrowe decides that
he is tired of waiting for step 3 above, makes the accusation "but you
had years to set aside time, and couldn't be bothered", as if to say
that I have been doing nothing all this time (svn disagrees). This
statement comes after making me wait literally years for a clear and
unambiguous answer as to exactly what is wrong with the apr_crypto and
apr_dbd APIs, so that I could move forward on the plan above.
As a project, we need to work together, we need to collaborate.
The right thing to have done would have been to have asked on the list
as to the status of apr_ldap, and what was blocking progress. The
answer to that question is written above, and would have been provided
had somebody just asked.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/2/2011 9:09 AM, Jeff Trawick wrote:
>
> What is the set of APR users which depend on the moderate help
> provided by apr-util 1.x for dealing with multiple LDAP toolkit? I
> don't know. I doubt that many users are impacted, and the moderate
> level of assistance provided by apr-util wasn't the normal APR
> experience anyway. Those users didn't step up to help at any rate.
I think you hit the nail on the head, better than I put it.
Even if it were to be proposed by a single maintainer, some would remain
critical of the probability that there isn't enough of a community around
ldap support.
If there were several, it would be much more warmly accepted.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4
build/apu-ldap.m4 configure.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jun 2, 2011 at 10:09 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Jun 2, 2011 at 7:10 AM, Graham Leggett <mi...@sharp.fm> wrote:
>> On 02 Jun 2011, at 1:19 AM, William A. Rowe Jr. wrote:
>>
>>> On 6/1/2011 5:37 PM, Graham Leggett wrote:
>>>>
>>>> I see a vote, and no on-list discussion that preceded it. Not only that,
>>>> I see a vote on
>>>> the dev@apr list proposing an as yet unheard of solution that concerns a
>>>> completely
>>>> separate project, with no discussion having happened on either project.
>>>> This is not how a
>>>> project at the ASF works.
>>>
>>> Quit whining, of course this is how an ASF project works; there was a
>>> discussion,
>>> it ate up a good part of the list bandwidth, with discussion and
>>> suggestions of
>>> how to fix, and no fix forthcoming, and a conclusive decision on list;
>>>
>>>
>>> http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3C5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com%3E
>>>
>>> Justin had brought this to the list from a f2f hackathon for a decision as
>>> this
>>> blocked 2.0 in 2009(!).
>>
>> "So, during the conversations we've had here in Amsterdam regarding
>> combining APR and APR-util". Another example of discussions taken and
>> decisions made off list.
>>
>> This is not how an ASF project works, and wearing my PMC member's hat, I
>> consider this continued practice a risk to this project.
>>
>>> but you had years to set aside time, and couldn't be bothered.
>>
>> I am thoroughly disgusted by this remark.
>>
>> I have spent weeks and weeks of my time on my dime solving RFC violations in
>> mod_cache that were contributed to us in 2003, in addition to a huge amount
>> of other work on fixing the mod_cache API in time for the imminent release
>> of httpd v2.4, and this is simply more important right now. A further
>> enormous time sink was resolving your issues you demanded fixed in the
>> apr_crypto API, which you carried on complaining about even after the work
>> was completed - you'd hadn't even noticed the work had been done.
>>
>> The Apache Way is community over code, a community working together makes
>> for high quality code that is safe to build upon. When one member of a
>> community starts behaving abusively towards other members of the community,
>> the code suffers. Again, wearing my PMC member's hat, this has got to stop.
>>
>>> (In the
>>> interim, I had to set aside time to make the merge to mod_ldap - that is
>>> how the ASF works, [s]he who does the work makes the decisions.)
>>
>> I have already declared my intention to veto any attempt to dump this code
>> in httpd. Our end users and vendors deserve to be treated better than this.
>>
>> Regards,
>> Graham
>
> There's a lot of extraneous information here which is not related to
> removing LDAP from APR 2.0-dev.
>
> What are the critical facts?
>
> LDAP support in APR 2.0:
>
> * there was [almost] no support for preserving the status quo; those
> that spoke up wanted either to make it a full API or drop it
> ** more wanted to drop it
> ** Graham offered to do the work to make it a full API
>
> * AFAIK we did not resolve the fact that more people spoke up for
> removal than for making it a full API ("tentative compromise"?)
>
> * nobody got around to either removing it or making it a full API for
> a long time afterwards, for the same multitude of reasons that other
> things do not get done
>
> * wrowe finally got around to take action, which was to yank it
> ** I dunno if that was preceded by a notice, which would have been
> "nice" (no, I haven't spent much time in my inbox :( )
>
> Any dispute so far?
>
> What is veto-able? Nothing, AFAICT. There's no technical issue.
>
> Separately, the current state of the code matches the group think when
> this was discussed before. If the group think changes, it can come
> right back in, in a state that matches the group think.
>
> Where are users left?
>
> httpd users aren't expected to be left out, but that's not our problem here
(since httpd is working on a solution that doesn't rely on APR)
> What is the set of APR users which depend on the moderate help
> provided by apr-util 1.x for dealing with multiple LDAP toolkit? I
> don't know. I doubt that many users are impacted, and the moderate
> level of assistance provided by apr-util wasn't the normal APR
> experience anyway. Those users didn't step up to help at any rate.
>
--
Born in Roswell... married an alien...
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4
build/apu-ldap.m4 configure.in
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jun 2, 2011 at 7:10 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 02 Jun 2011, at 1:19 AM, William A. Rowe Jr. wrote:
>
>> On 6/1/2011 5:37 PM, Graham Leggett wrote:
>>>
>>> I see a vote, and no on-list discussion that preceded it. Not only that,
>>> I see a vote on
>>> the dev@apr list proposing an as yet unheard of solution that concerns a
>>> completely
>>> separate project, with no discussion having happened on either project.
>>> This is not how a
>>> project at the ASF works.
>>
>> Quit whining, of course this is how an ASF project works; there was a
>> discussion,
>> it ate up a good part of the list bandwidth, with discussion and
>> suggestions of
>> how to fix, and no fix forthcoming, and a conclusive decision on list;
>>
>>
>> http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3C5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com%3E
>>
>> Justin had brought this to the list from a f2f hackathon for a decision as
>> this
>> blocked 2.0 in 2009(!).
>
> "So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util". Another example of discussions taken and
> decisions made off list.
>
> This is not how an ASF project works, and wearing my PMC member's hat, I
> consider this continued practice a risk to this project.
>
>> but you had years to set aside time, and couldn't be bothered.
>
> I am thoroughly disgusted by this remark.
>
> I have spent weeks and weeks of my time on my dime solving RFC violations in
> mod_cache that were contributed to us in 2003, in addition to a huge amount
> of other work on fixing the mod_cache API in time for the imminent release
> of httpd v2.4, and this is simply more important right now. A further
> enormous time sink was resolving your issues you demanded fixed in the
> apr_crypto API, which you carried on complaining about even after the work
> was completed - you'd hadn't even noticed the work had been done.
>
> The Apache Way is community over code, a community working together makes
> for high quality code that is safe to build upon. When one member of a
> community starts behaving abusively towards other members of the community,
> the code suffers. Again, wearing my PMC member's hat, this has got to stop.
>
>> (In the
>> interim, I had to set aside time to make the merge to mod_ldap - that is
>> how the ASF works, [s]he who does the work makes the decisions.)
>
> I have already declared my intention to veto any attempt to dump this code
> in httpd. Our end users and vendors deserve to be treated better than this.
>
> Regards,
> Graham
There's a lot of extraneous information here which is not related to
removing LDAP from APR 2.0-dev.
What are the critical facts?
LDAP support in APR 2.0:
* there was [almost] no support for preserving the status quo; those
that spoke up wanted either to make it a full API or drop it
** more wanted to drop it
** Graham offered to do the work to make it a full API
* AFAIK we did not resolve the fact that more people spoke up for
removal than for making it a full API ("tentative compromise"?)
* nobody got around to either removing it or making it a full API for
a long time afterwards, for the same multitude of reasons that other
things do not get done
* wrowe finally got around to take action, which was to yank it
** I dunno if that was preceded by a notice, which would have been
"nice" (no, I haven't spent much time in my inbox :( )
Any dispute so far?
What is veto-able? Nothing, AFAICT. There's no technical issue.
Separately, the current state of the code matches the group think when
this was discussed before. If the group think changes, it can come
right back in, in a state that matches the group think.
Where are users left?
httpd users aren't expected to be left out, but that's not our problem here.
What is the set of APR users which depend on the moderate help
provided by apr-util 1.x for dealing with multiple LDAP toolkit? I
don't know. I doubt that many users are impacted, and the moderate
level of assistance provided by apr-util wasn't the normal APR
experience anyway. Those users didn't step up to help at any rate.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Jun 2011, at 1:19 AM, William A. Rowe Jr. wrote:
> On 6/1/2011 5:37 PM, Graham Leggett wrote:
>> I see a vote, and no on-list discussion that preceded it. Not only
>> that, I see a vote on
>> the dev@apr list proposing an as yet unheard of solution that
>> concerns a completely
>> separate project, with no discussion having happened on either
>> project. This is not how a
>> project at the ASF works.
>
> Quit whining, of course this is how an ASF project works; there was
> a discussion,
> it ate up a good part of the list bandwidth, with discussion and
> suggestions of
> how to fix, and no fix forthcoming, and a conclusive decision on list;
>
> http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3C5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com%3E
>
> Justin had brought this to the list from a f2f hackathon for a
> decision as this
> blocked 2.0 in 2009(!).
"So, during the conversations we've had here in Amsterdam regarding
combining APR and APR-util". Another example of discussions taken and
decisions made off list.
This is not how an ASF project works, and wearing my PMC member's hat,
I consider this continued practice a risk to this project.
> but you had years to set aside time, and couldn't be bothered.
I am thoroughly disgusted by this remark.
I have spent weeks and weeks of my time on my dime solving RFC
violations in mod_cache that were contributed to us in 2003, in
addition to a huge amount of other work on fixing the mod_cache API in
time for the imminent release of httpd v2.4, and this is simply more
important right now. A further enormous time sink was resolving your
issues you demanded fixed in the apr_crypto API, which you carried on
complaining about even after the work was completed - you'd hadn't
even noticed the work had been done.
The Apache Way is community over code, a community working together
makes for high quality code that is safe to build upon. When one
member of a community starts behaving abusively towards other members
of the community, the code suffers. Again, wearing my PMC member's
hat, this has got to stop.
> (In the
> interim, I had to set aside time to make the merge to mod_ldap -
> that is
> how the ASF works, [s]he who does the work makes the decisions.)
I have already declared my intention to veto any attempt to dump this
code in httpd. Our end users and vendors deserve to be treated better
than this.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/1/2011 5:37 PM, Graham Leggett wrote:
> I see a vote, and no on-list discussion that preceded it. Not only that, I see a vote on
> the dev@apr list proposing an as yet unheard of solution that concerns a completely
> separate project, with no discussion having happened on either project. This is not how a
> project at the ASF works.
Quit whining, of course this is how an ASF project works; there was a discussion,
it ate up a good part of the list bandwidth, with discussion and suggestions of
how to fix, and no fix forthcoming, and a conclusive decision on list;
http://mail-archives.apache.org/mod_mbox/apr-dev/200903.mbox/%3C5c902b9e0903240326r3222ac90k15dcb7f34d2d1587@mail.gmail.com%3E
Justin had brought this to the list from a f2f hackathon for a decision as this
blocked 2.0 in 2009(!).
You alone voted + offered to fix; bnichnoles, trawick and bojan supported
a fix if one was offered.
jerenkrantz, pquerna, wrowe, mturk, issac, and jorton voted to remove from apr.
This is decided not only by vote, but by inaction since 2009. (No, 2009 was
not the first discussion on list, either. It was the conclusive discussion.)
You suggested;
> I don't see any problem with completely wrapping the LDAP API. It will
> solve the single-LDAP-toolkit problem above.
but nobody is doing it, nobody has done it.
You suggested;
> - When I get a chance to set aside some time to sort out the LDAP
> abstraction, I don't want to find people saying afterwards "oh, but I
> thought we weren't doing LDAP any more"
but you had years to set aside time, and couldn't be bothered. (In the
interim, I had to set aside time to make the merge to mod_ldap - that is
how the ASF works, [s]he who does the work makes the decisions.)
You asked;
> Can we move everything else, and
> leave apr-ldap in a legacy branch until someone has the time to get this
> done right for apr-2.0?
and it is so ( apr/apr-util/branches/1.4.x/ ).
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
On 31 May 2011, at 8:48 PM, William A. Rowe Jr. wrote:
> Of course it has been discussed, discussed, and discussed again, and
> experienced
> a complete failure to launch.
>
> Rowe, Trawick, Erenkrantz and Orton voted to drop apr_ldap and give it
> over to httpd to maintain if they want it 12 1/2 months ago. Whether
> httpd does or does not want it is really a topic for that dev list.
>
> http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3C4BD46614.6010503@rowe-clan.net%3E
> http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3CAANLkTinKzmDYbxo2VggZLOxPY72mH0OReK-kUeSGJSa3@mail.gmail.com%3E
I see a vote, and no on-list discussion that preceded it. Not only
that, I see a vote on the dev@apr list proposing an as yet unheard of
solution that concerns a completely separate project, with no
discussion having happened on either project. This is not how a
project at the ASF works.
> The interest in 'doing something someday' blocks APR v2.0 release,
> and blocking releases by inaction is always unacceptable at the ASF.
> It is the equivilant of leaving trunk in a not-compiling state (which
> I did only momentarily).
This issue does not block the APR v2.0 release, because this API is
already in the APR v1.0 release and has been for many years. One
person deciding they don't like a released API does not constitute
grounds for a blocker of any kind.
> We now have something to review for apr_crypto, thanks to your
> efforts,
> along with choice between libxml2 and expat, and my last project is to
> work out untangling apr 2.x from apr-iconv, which is one more
> unmaintained
> code base to deprecate.
Leaving end users to discover that whole APIs have mysteriously
disappeared without warning or explanation, without those APIs having
been marked as deprecated, is grounds for a veto. So is the idea that
another project will tolerate a code dump from one project to another,
with the corresponding disruption to vendors that will result. In
addition, APR has been a standalone library, depended on by many
projects external to the ASF for many years, APR is not part of httpd,
and code isn't interchangeable between them.
I have a proposal however to avoid the need for that, concerning the
unfinished work combining apr and apr-util (something else performed
without any notice or discussion on this list). I will follow up with
another message.
> Nobody needs to stop anything on httpd v2.4, I am in the process of
> hooking up apr-2 correctly for that build for win32. Quick review on
> unix indicates it works correctly. But that would be a dev@httpd
> discussion.
Yeah, they do need to stop everything. Getting Roy's mod_cache
blockers fixed on httpd before httpd's API is baked is more important
than rewriting your API for you, and not only am I prepared to do one
at a time, I am supposed to be having a holiday.
Regards,
Graham
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/31/2011 1:13 PM, Graham Leggett wrote:
>
> 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?
Of course it has been discussed, discussed, and discussed again, and experienced
a complete failure to launch.
Rowe, Trawick, Erenkrantz and Orton voted to drop apr_ldap and give it
over to httpd to maintain if they want it 12 1/2 months ago. Whether
httpd does or does not want it is really a topic for that dev list.
http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3C4BD46614.6010503@rowe-clan.net%3E
http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3CAANLkTinKzmDYbxo2VggZLOxPY72mH0OReK-kUeSGJSa3@mail.gmail.com%3E
> 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?
The interest in 'doing something someday' blocks APR v2.0 release,
and blocking releases by inaction is always unacceptable at the ASF.
It is the equivilant of leaving trunk in a not-compiling state (which
I did only momentarily).
We now have something to review for apr_crypto, thanks to your efforts,
along with choice between libxml2 and expat, and my last project is to
work out untangling apr 2.x from apr-iconv, which is one more unmaintained
code base to deprecate.
Nobody needs to stop anything on httpd v2.4, I am in the process of
hooking up apr-2 correctly for that build for win32. Quick review on
unix indicates it works correctly. But that would be a dev@httpd
discussion.
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4
configure.in
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/30/2011 2:48 PM, Graham Leggett wrote:
> On 29 May 2011, at 4:59 PM, wrowe@apache.org wrote:
>
>> URL: http://svn.apache.org/viewvc?rev=1128885&view=rev
>> Log:
>> Begin refactoring to prepare for ldap removal
>
> Would it be possible to make an apr-ldap-legacy branch before you do this?
>
> It would suck for end users if a body of code should suddenly disappear, and there was
> nothing to point where it went or what the future plans for it were.
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.
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. Anyone following trunk to the commit "Remove LDAP
API" and taking r -1 can have a copy, or from the 1.x util tarballs.
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).
So we can be clear ldap is dropped from apr-2.x, as all of the recent votes
on the subject have indicated, and as you suggest, we need to explicitly
mention that in any beta/release 2.0 announcement.
But these patches you mention, they are simply to ensure that important
parts of apr[util] conf logic don't fall away with the dropping of ldap.
So no, after wasting a week on untangling this mess, I don't see a point
to create new dead branches.