William A. Rowe, Jr. wrote:
No - the most important bit is to start hiding the details in apu_private.h
and quit publicizing the sdk versions, define mapping wrappers, etc.
Once everything that aprutil-1 elects to do is hidden inside aprutil-1.so,
and the interface is always the same (no matter
The prototype for apr_ldap_info() in apr_ldap_init.c is missing. It
needs to be added to apr_ldap_init.h
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
Graham Leggett [EMAIL PROTECTED] Tuesday, August 03, 2004
At 04:04 PM 8/2/2004, Graham Leggett wrote:
David Reid wrote:
The main fooness is in apr_ldap_url.c. Can we not mark this code as
deprecated in v1.0, which should hopefully warn alert coders that the code
should not be used, and can be pointed out to coders who are asleep
otherwise if they
At 12:53 PM 8/2/2004, David Reid wrote:
Graham Leggett wrote:
William A. Rowe, Jr. wrote:
I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce
the entire feature in the new APR 1.1 (which we can start development
on immediately.) And that presumes httpd 2.1/2.2 will depend on
On Mon, 2 Aug 2004, William A. Rowe, Jr. wrote:
Least action is fork 1.1, cvs rm the offensive files, and change about
10 lines of the makefiles and rip out the ldap detection. Pretty trivial.
Deprecating means we support this junk till 2.0 releases.
+1. If the API is really that broken,
--On Tuesday, August 3, 2004 12:16 AM -0400 Cliff Woolley
[EMAIL PROTECTED] wrote:
+1. If the API is really that broken, it's better to remove it
completely and add something better later.
Under our compatibility rules, we can remove apr_ldap_* in APR 1.0 and add
it back in APR 1.1. That's my
William A. Rowe, Jr. wrote:
Right now it does little. Graham and I agree on the right solution,
to abstract out the logic to do SSL connections in a portable way.
There will be no need for the 'application developer' to know which
toolkit they are using. We will make that transparent.
This
Justin Erenkrantz wrote:
Under our compatibility rules, we can remove apr_ldap_* in APR 1.0 and
add it back in APR 1.1. That's my recommendation here. -- justin
As I have just overhauled apr_ldap, I would ask that people check first
which parts of apr_ldap need to be removed and/or fixed.
I
At 06:08 AM 8/3/2004, Graham Leggett wrote:
William A. Rowe, Jr. wrote:
Right now it does little. Graham and I agree on the right solution,
to abstract out the logic to do SSL connections in a portable way.
There will be no need for the 'application developer' to know which
toolkit they are
Therefore I ask: How important is LDAP v2? Can we just chop LDAP v2
support for APR 1.0 - we get rid of the macros and the spare
functions.
We can do LDAP v2.0 support (as opposed to v3.0 support we do by
default) in the proper APR way later.
+1, V3 has been around for a while. Let's support
At 12:11 PM 8/1/2004, Graham Leggett wrote:
David Reid wrote:
So I see. I'll tag roll APR RC5 later on tonight and hopefully as soon as
apr-util is patched for apr-config I'll be able to roll.
Would it be possible to include the recent LDAP changes in v1.0.0? They fix
some LDAP fooness that
William A. Rowe, Jr. wrote:
I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce
the entire feature in the new APR 1.1 (which we can start development
on immediately.) And that presumes httpd 2.1/2.2 will depend on the
1.1 release of apr-util.
I hate to hold up 1.0 any
Graham Leggett wrote:
William A. Rowe, Jr. wrote:
I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce
the entire feature in the new APR 1.1 (which we can start development
on immediately.) And that presumes httpd 2.1/2.2 will depend on the
1.1 release of apr-util.
I hate to
David Reid wrote:
The main fooness is in apr_ldap_url.c. Can we not mark this code as
deprecated in v1.0, which should hopefully warn alert coders that the
code should not be used, and can be pointed out to coders who are
asleep otherwise if they moan.
How much work is needed to fix it? What
David Reid wrote:
So I see. I'll tag roll APR RC5 later on tonight and hopefully as soon
as apr-util is patched for apr-config I'll be able to roll.
Would it be possible to include the recent LDAP changes in v1.0.0? They
fix some LDAP fooness that shouldn't get out the door if at all possible.
At 08:18 AM 7/30/2004, David Reid wrote:
However, we need to remove the APR_STATUS_IS_SUCCESS macro before 1.0 goes
out, because otherwise we are stuck with it for a very long time.
There were win32 comments from Brane? Is someone going to commit the changes
needed?
What changes? Note in
Justin Erenkrantz wrote:
--On Friday, July 30, 2004 8:33 AM -0400 Ryan Bloom [EMAIL PROTECTED]
wrote:
However, we need to remove the APR_STATUS_IS_SUCCESS macro before 1.0
goes
out, because otherwise we are stuck with it for a very long time.
It's gone now. ;-)
So I see. I'll tag roll APR
On Jul 30, 2004, at 7:33 AM, Ryan Bloom wrote:
I don't understand why this is still being discussed. The patch makes
sense, it solves a real problem and just needs to be committed and
tested.
+1 on adding it to 1.0.0RC5 so that we can get the release out.
However, we need to remove the
18 matches
Mail list logo
