On 05/23/2008 10:05 PM, William A. Rowe, Jr. wrote:
Joe Orton wrote:
More review:
1) the DSO-loading stuff is not thread-safe (dsos global not
mutex-protected) yet apr_ldap_init would/could/should be; it's not
documented to explicitly *not* be thread-safe, anyway.
The caller must obtain
Amazing how consistently someone's vetoes only arrive after proposals
have been offered for over a week and developers had already invested
the time to author the solution they originally proposed.
Simply amazing.
Bill
On May 15, 2008 William A. Rowe, Jr. wrote:
What is interesting is that a
Joe Orton wrote:
Ah right, you mean adding an API to expose that. Yeah, makes sense I
suppose, but this is kind of piling on more and more layers of
workarounds. An alternative maybe is to just create another unparented
global pool here using the new 1.3 pool_core_create_ex API.
Trouble i
On Fri, May 23, 2008 at 11:50:35AM -0500, William Rowe wrote:
> Joe Orton wrote:
>>> Then do we all decide that there is a global pool and an API to obtain it?
>>> I know how to do this, but I'm just asking if that's how to go.
>>
>> I'm not sure what you're asking here. Starting in 1.3.x there ca
Joe Orton wrote:
Then do we all decide that there is a global pool and an API to obtain it?
I know how to do this, but I'm just asking if that's how to go.
I'm not sure what you're asking here. Starting in 1.3.x there can be
multiple global pools each under control of separate consumers.
Th
On Fri, May 23, 2008 at 09:23:43AM -0500, William Rowe wrote:
> There *IS* a build system schema change. I don't see where we wrote out
> the versioning rules for building APR. But I beg to differ with you, this
> change does not violate versioning guidelines.
I guess it's reasonable to argue th
On Fri, May 23, 2008 at 04:27:59PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>
>> As expected, this breaks source compatibility, as defined by the APR
>> versioning guidelines. The fact that you need to patch httpd to make
>> httpd continue to build seems like ample demonstration that sour
William A. Rowe, Jr. wrote:
removing -lldap -llber from ./configure --with-ldap builds into a seperate
recoverable ./apu-1-config --ldap-libs flag;
[ ] Breaks our versioning contract
[X] Does not break our versioning contract
The acid test is whether an APR consuming application binary (eg
removing -lldap -llber from ./configure --with-ldap builds into a seperate
recoverable ./apu-1-config --ldap-libs flag;
[ ] Breaks our versioning contract
[X] Does not break our versioning contract
Joe Orton wrote:
On Thu, May 15, 2008 at 05:17:00PM -0500, William Rowe wrote:
http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch
As expected, this breaks source compatibility, as defined by the APR
versioning guidelines. The fact that you need to patch httpd to make
httpd continu
Joe Orton wrote:
As expected, this breaks source compatibility, as defined by the APR
versioning guidelines. The fact that you need to patch httpd to make
httpd continue to build seems like ample demonstration that source
compatibility is broken ;) So it's 2.x material, and because it's 2.x
Joe Orton wrote:
On Thu, May 15, 2008 at 05:17:00PM -0500, William Rowe wrote:
http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch
As expected, this breaks source compatibility, as defined by the APR
versioning guidelines. The fact that you need to patch httpd to make
httpd continu
On Thu, May 15, 2008 at 05:17:00PM -0500, William Rowe wrote:
> http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch
As expected, this breaks source compatibility, as defined by the APR
versioning guidelines. The fact that you need to patch httpd to make
httpd continue to build seems li
Eric Covener wrote:
+1 on wrapping it all in 2.0, but I don't think the versioning
restrictions allow apr-util to stop linking against LDAP in 1.3 -- for
example applications that load ldap symbols privately ("not at all"
shouldn't be an issue because they can't do anything useful with the
apr-
On Thu, May 15, 2008 at 6:39 PM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Wrapping the LDAP library however does make things cleaner, and does empower
> us to create standard behaviour should a future LDAP library come along and
> act funny. So if you want to wrap all the LDAP functions for v2.
William A. Rowe, Jr. wrote:
What is interesting is that a patched apr-1.3.x remains binary compatible.
Simply ./configuring --enable-dbd-dso (really should be --enable-dsos) in
combination with --with-ldap will toggle the behavior.
Am I correct in understanding that this brings the LDAP bindin
William A. Rowe, Jr. wrote:
http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch
http://people.apache.org/~wrowe/ldap/httpd-2.x-ldap.patch illustrates how
this translates for such a patched apr-util-1.
As an illustration, here are the results from this change on three example
binaries,
http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch
is the very first draft of a proposal which begins to break apart the
libldap (& liblber) bindings from the core libaprutil-1 and consuming
applications.
You can see, for reference, an earlier patch in that tree that broke ldap
from ht
18 matches
Mail list logo
