[answering this backwards]
On 08 Jul 2011, at 4:10 AM, Nick Kew wrote:
I am therefore vetoing this move of apr_ldap from APR to httpd.
Hang on! How long ago did this move happen, and when did you
first raise concerns?
The move happened on the 31st of May, and my concerns were first
On Thu, Jul 07, 2011 at 11:59:20PM +0200, Graham Leggett wrote:
On 04 Jul 2011, at 6:48 PM, Joe Orton wrote:
It's incumbent on you to provide specific technical objections if
vetoing code, not this hand-waving objections must exist because
of X.
I have already done so. If you disagree
On 08 Jul 2011, at 6:01 PM, Joe Orton wrote:
I have already done so. If you disagree with the objection, or do
not understand the objection, engage the objection directly so it
can be resolved.
I've done exactly that twice in this thread. I have not seen any
attempt to concisely express a
On 04 Jul 2011, at 6:48 PM, Joe Orton wrote:
It's incumbent on you to provide specific technical objections if
vetoing code, not this hand-waving objections must exist because of
X.
I have already done so. If you disagree with the objection, or do not
understand the objection, engage the
On 25 Jun 2011, at 21:11, Graham Leggett wrote:
This is not so, to fix this, you would need to wrap every single LDAP API
function call[1] in an optional function, and if you did that, you would
solve the problem that caused you to want to remove apr_ldap from APR in the
first place,
On 7/7/2011 9:10 PM, Nick Kew wrote:
I am therefore vetoing this move of apr_ldap from APR to httpd.
Hang on! How long ago did this move happen, and when did you
first raise concerns?
His first attempt at vetoing this change was in 2009, accompanied
by an assertion that he would address
- Original Message -
On 04 Jul 2011, at 11:11 AM, Joe Orton wrote:
mod_ldap - An LDAP shared memory cache
mod_authnz_ldap - A user of the LDAP shared memory cache
The LDAP API exposes way more functionality than mod_ldap exposes,
so while you may have fixed the problem for
On 07 Jul 2011, at 12:44 AM, Igor Galić wrote:
I have already stated the basis for the veto: every single apparent
flaw in the apr_ldap code that caused wrowe to remove it from APR is
still present in the code that wrowe dumped into httpd. If it's not
It is, fortunately, not in httpd's core.
On Thursday 30 June 2011, Graham Leggett wrote:
On 27 Jun 2011, at 8:29 PM, Stefan Fritsch wrote:
This is fixed by calling the ldap_get_option() function
described in section 9.2 of
http://www-archive.mozilla.org/directory/ietf-docs/draft-ietf-ld
ap ext-ldap-c-api-05.txt . There is no
On Mon, Jun 27, 2011 at 03:19:37PM +0200, Graham Leggett wrote:
mod_ldap - An LDAP shared memory cache
mod_authnz_ldap - A user of the LDAP shared memory cache
The LDAP API exposes way more functionality than mod_ldap exposes,
so while you may have fixed the problem for the special case that
On 04 Jul 2011, at 11:11 AM, Joe Orton wrote:
mod_ldap - An LDAP shared memory cache
mod_authnz_ldap - A user of the LDAP shared memory cache
The LDAP API exposes way more functionality than mod_ldap exposes,
so while you may have fixed the problem for the special case that is
mod_authnz_ldap,
On Mon, Jul 04, 2011 at 11:43:33AM +0200, Graham Leggett wrote:
I have already stated the basis for the veto: every single apparent
flaw in the apr_ldap code that caused wrowe to remove it from APR is
still present in the code that wrowe dumped into httpd.
It's incumbent on you to provide
On 27 Jun 2011, at 4:04 PM, William A. Rowe Jr. wrote:
And I'd nix your definition of mod_ldap... if it an ldap shared cache
provider then it should have been suitably named. One can omit
such a
feature and still use mod_authnz_ldap. Of course, that was not
possible
because
On 27 Jun 2011, at 8:29 PM, Stefan Fritsch wrote:
This is fixed by calling the ldap_get_option() function described
in section 9.2 of
http://www-archive.mozilla.org/directory/ietf-docs/draft-ietf-ldap
ext-ldap-c-api-05.txt . There is no need to move the code to
support this, this can be
On Sat, Jun 25, 2011 at 10:11:20PM +0200, Graham Leggett wrote:
On 06 Jun 2011, at 11:53 PM, William A. Rowe Jr. wrote:
Since the move from apr-util-ldap to ap_ldap, mod_ldap needs to be
loaded before mod_authnz_ldap. This is somewhat annoying because the
default httpd.conf tries to load
On 27 Jun 2011, at 12:28 PM, Joe Orton wrote:
This is not so, to fix this, you would need to wrap every single
LDAP API function call[1] in an optional function, and if you did
that, you would solve the problem that caused you to want to remove
apr_ldap from APR in the first place, making the
On 6/27/2011 8:19 AM, Graham Leggett wrote:
mod_ldap - An LDAP shared memory cache
mod_authnz_ldap - A user of the LDAP shared memory cache
The LDAP API exposes way more functionality than mod_ldap exposes, so while
you may have
fixed the problem for the special case that is
On 6/27/2011 9:04 AM, William A. Rowe Jr. wrote:
Of course, following Joe's commit, we no longer have the module load order
issue (thanks Joe! I'll review win32 within three days per Gregg's notes).
Just read Jim's post, which sounds great. I'll get to this tonight.
On Sunday 26 June 2011, Graham Leggett wrote:
On 26 Jun 2011, at 3:16 PM, Stefan Fritsch wrote:
Nobody said that this would be magically fixed by moving the
stuff to HTTPD. But it means that the apr libraries are no
longer involved in the mess, which is already very helpful for
On Sun, 26 Jun 2011, Graham Leggett wrote:
On 25 Jun 2011, at 11:24 PM, Stefan Fritsch wrote:
This is not so, to fix this, you would need to wrap every single
LDAP API function call[1] in an optional function, and if you did
that, you would solve the problem that caused you to want to
remove
On 26 Jun 2011, at 3:16 PM, Stefan Fritsch wrote:
Nobody said that this would be magically fixed by moving the stuff
to HTTPD. But it means that the apr libraries are no longer involved
in the mess, which is already very helpful for distributions like
Debian. With the apr 1.x situation, an
On 06 Jun 2011, at 11:53 PM, William A. Rowe Jr. wrote:
Since the move from apr-util-ldap to ap_ldap, mod_ldap needs to be
loaded before mod_authnz_ldap. This is somewhat annoying because the
default httpd.conf tries to load mod_authnz_ldap first. Any ideas how
to fix this or do we just change
On Saturday 25 June 2011, Graham Leggett wrote:
On 06 Jun 2011, at 11:53 PM, William A. Rowe Jr. wrote:
I believe the entire fix may be an entry point to
apr_ldap_parse_uri (check your own binaries to confirm).
Setting up a single entry point should be trivial, if its
appropriate.
On 25 Jun 2011, at 11:24 PM, Stefan Fritsch wrote:
This is not so, to fix this, you would need to wrap every single
LDAP API function call[1] in an optional function, and if you did
that, you would solve the problem that caused you to want to
remove apr_ldap from APR in the first place, making
On Thursday 23 June 2011, William A. Rowe Jr. wrote:
On 6/22/2011 3:13 PM, Stefan Fritsch wrote:
On Wednesday 22 June 2011, William A. Rowe Jr. wrote:
On 6/18/2011 7:59 AM, Stefan Fritsch wrote:
mod_vhost_ldap already exists and is a user of mod_ldap. So -1
to merging mod_ldap with
On 6/18/2011 7:59 AM, Stefan Fritsch wrote:
mod_vhost_ldap already exists and is a user of mod_ldap. So -1 to
merging mod_ldap with mod_authnz_ldap.
Can anyone do a quick check if it builds against mod_ldap today with
apr 2.0, since the recent changes I made moving apr_ - ap_ ?
On Wednesday 22 June 2011, William A. Rowe Jr. wrote:
On 6/18/2011 7:59 AM, Stefan Fritsch wrote:
mod_vhost_ldap already exists and is a user of mod_ldap. So -1 to
merging mod_ldap with mod_authnz_ldap.
Can anyone do a quick check if it builds against mod_ldap today
with apr 2.0, since
On 6/22/2011 3:13 PM, Stefan Fritsch wrote:
On Wednesday 22 June 2011, William A. Rowe Jr. wrote:
On 6/18/2011 7:59 AM, Stefan Fritsch wrote:
mod_vhost_ldap already exists and is a user of mod_ldap. So -1 to
merging mod_ldap with mod_authnz_ldap.
Can anyone do a quick check if it builds
On Friday 17 June 2011, William A. Rowe Jr. wrote:
Is there any remaining benefit from the mod_ldap/mod_authnz_ldap
split? Couldn't we just link it all into one big DSO and stop
faffing around with optional functions? It might be simpler.
I believe there is. I remember someone talking
On Mon, Jun 06, 2011 at 04:53:13PM -0500, William Rowe wrote:
On 6/6/2011 4:17 PM, Stefan Fritsch wrote:
Since the move from apr-util-ldap to ap_ldap, mod_ldap needs to be
loaded before mod_authnz_ldap. This is somewhat annoying because the
default httpd.conf tries to load mod_authnz_ldap
Since the move from apr-util-ldap to ap_ldap, mod_ldap needs to be
loaded before mod_authnz_ldap. This is somewhat annoying because the
default httpd.conf tries to load mod_authnz_ldap first. Any ideas how
to fix this or do we just change the order in the default httpd.conf?
On 6/6/2011 4:17 PM, Stefan Fritsch wrote:
Since the move from apr-util-ldap to ap_ldap, mod_ldap needs to be
loaded before mod_authnz_ldap. This is somewhat annoying because the
default httpd.conf tries to load mod_authnz_ldap first. Any ideas how
to fix this or do we just change the order
32 matches
Mail list logo
