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 spe
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 d
[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
raise
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 addr
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, m
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 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. I
- 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 t
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 . The
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 s
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, 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
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 mod_authnz_l
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 supporte
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
> > di
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 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 mod_au
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 wh
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 l
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 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 a
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 t
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 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 t
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_lda
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
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, s
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 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
On 6/17/2011 7:08 AM, Joe Orton wrote:
> 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
>>>
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_authn
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 or
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?
33 matches
Mail list logo