Hello everyone!
I want to use apr-debug and apr-util-debug to get the debug information of
apr and apr-util!
But I do not know how to use it? Is there any reference?
I have installed apr-debug-1.2.11-1mdv2008.0.i586.rpm and
apr-util-debug-1.2.10-1mdv2008.0.i586.rpm in my computer, and h
On Wed, 2009-03-25 at 01:34 +0200, Graham Leggett wrote:
> mod_ldap is an LDAP cache, it isn't an LDAP abstraction layer (that's
> what apr-ldap is for).
I meant, maybe there is code in there that already abstract a lot of
that stuff, which can then be reused, given it works with many LDAP
implem
Bojan Smojver wrote:
[x] Fix the LDAP interface to be a complete/full LDAP abstraction
[ ] Remove the LDAP interfaces from APR
Provided most of the code can be taken from mod_ldap. In other words,
more people can use it if it is in APR.
But, if it is hard to do (i.e. if mod_ldap doesn't abstr
Since I had the need for a function, which shuffles members of an apr_array_t,
I have written one which conforms to the style of apr and which could be added
to future versions of the apr library. I would be glad to donate the sources:
Source: http://modicpquery.googlecode.com/svn/trunk/mod_icpquer
On Tue, 2009-03-24 at 11:26 +0100, Justin Erenkrantz wrote:
> [x] Fix the LDAP interface to be a complete/full LDAP abstraction
> [ ] Remove the LDAP interfaces from APR
Provided most of the code can be taken from mod_ldap. In other words,
more people can use it if it is in APR.
But, if it is har
Ruediger Pluem wrote:
On 24.03.2009 17:41, Mladen Turk wrote:
Joe Orton wrote:
On the topic of how to split up APR into multiple libraries, I had a
look through the current directories, and a first cut at how I'd
propose to split the code up would be:
(directory -> library-name [dependencies
On Tue, Mar 24, 2009 at 05:43:52PM +0100, William Rowe wrote:
> Mladen Turk wrote:
>> Joe Orton wrote:
>>> On the topic of how to split up APR into multiple libraries, I had a
>>> look through the current directories, and a first cut at how I'd
>>> propose to split the code up would be:
...
>>
On 24.03.2009 17:41, Mladen Turk wrote:
> Joe Orton wrote:
>> On the topic of how to split up APR into multiple libraries, I had a
>> look through the current directories, and a first cut at how I'd
>> propose to split the code up would be:
>>
>> (directory -> library-name [dependencies])
>>
>>
Mladen Turk wrote:
Joe Orton wrote:
On the topic of how to split up APR into multiple libraries, I had a
look through the current directories, and a first cut at how I'd
propose to split the code up would be:
(directory -> library-name [dependencies])
buckets -> libapr-buckets
crypto -
Joe Orton wrote:
On the topic of how to split up APR into multiple libraries, I had a
look through the current directories, and a first cut at how I'd propose
to split the code up would be:
(directory -> library-name [dependencies])
buckets -> libapr-buckets
crypto -> libapr-crypto
db
On Tue, Mar 24, 2009 at 04:58:02PM +0200, Graham Leggett wrote:
> If I am understanding you correctly, for a library like dbd that
> contains sub-libraries, you would have libapr-db, which in turn loads
> dynamic modules called (say) libapr-db-pgsql (etc)?
apr_dbd.c would be linked into a libr
Joe Orton wrote:
On the topic of how to split up APR into multiple libraries, I had a
look through the current directories, and a first cut at how I'd propose
to split the code up would be:
(directory -> library-name [dependencies])
buckets -> libapr-buckets
crypto -> libapr-crypto
d
>>> On 3/24/2009 at 7:47 AM, in message
<4239a4320903240647x12f09613l6eb58974cd656...@mail.gmail.com>, Paul Querna
wrote:
> On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett wrote:
>> William A. Rowe, Jr. wrote:
>>
>>> We've actually discussed this on list for several years, and your comments
>>> f
>>> On 3/24/2009 at 4:26 AM, in message
<5c902b9e0903240326r3222ac90k15dcb7f34d2d1...@mail.gmail.com>, Justin
Erenkrantz wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our tre
On the topic of how to split up APR into multiple libraries, I had a
look through the current directories, and a first cut at how I'd propose
to split the code up would be:
(directory -> library-name [dependencies])
buckets -> libapr-buckets
crypto -> libapr-crypto
dbd -> libapr-db [lib
William A. Rowe, Jr. wrote:
So it sounds that you will accept copying apr-ldap into a sandbox and
would like to continue to pursue it and come up with something workable.
In the meantime, the /repos/asf/apr/apr-util/trunk/ WILL disappear with
nothing but a SEE_OTHER file. So we can certainly p
Graham Leggett wrote:
A far more pragmatic approach to this problem is this:
"We want to combine apr and apr-util into apr-2.0, but we don't want to
go to the effort of moving across apr-ldap, because there are moves
afoot to have this abstraction redone. Can we move everything else, and
lea
On Tue, Mar 24, 2009 at 11:26:36AM +0100, Justin Erenkrantz wrote:
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [X] Remove the LDAP interfaces from APR
Folding this code into mod_ldap seems like the right thing to do.
Regards, Joe
Paul Querna wrote:
It will always be in the subversion history.
If its redone and isn't a leaky abstraction, then sure, we can look at
bringing it back, this vote doesn't stop that from happening.
This vote is about what we want to do in the short term, and frankly
the LDAP stuff has staggered
On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>
>> We've actually discussed this on list for several years, and your comments
>> for years have been 'yea, that's on me, I aught to fix that'. Now that
>> some folks would like to move forwards towards completi
William A. Rowe, Jr. wrote:
We've actually discussed this on list for several years, and your comments
for years have been 'yea, that's on me, I aught to fix that'. Now that
some folks would like to move forwards towards completing APR 2.0, there
will be more of these sorts of votes.
A far mo
>>
>> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
>> [X] Remove the LDAP interfaces from APR
>>
Paul Querna wrote:
> Hi,
>
> At ApacheCon, we have had a discussion about APR 2.x and APR-Util.
>
> In the short term, we would like to merge the two libraries, into one
> monolithic giant APR 2 library.
>
> In the long term, we would like to split out things that add extra
> dependencies to the
Graham Leggett wrote:
This vote is completely premature.
What was supposed to happen is that a discussion be kicked off **on the
mailing list**, so that people fully understand why the LDAP abstraction
is as it is, and in turn people can come up with a properly thought out
way forward to add
Bing Swen wrote:
"Paul Querna" wrote on Tuesday, March 24, 2009 6:22 PM
In the short term, we would like to merge the two libraries, into one
monolithic giant APR 2 library.
This is very good for simplifying the updating of the library.
What about apr-iconv? It still has a reduced function s
Jeff Trawick wrote:
I feel like voting for "Fix the LDAP interface..." but I don't see
anybody caring but httpd, and the widespread use of Linux/OpenLDAP for
developing the apps in our space has made this an unstrategic problem to
solve.
I agree, it seems apr_ldap can be entirely in mod_lda
On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett wrote:
> Jeff Trawick wrote:
>
> any counter-knowledge/opinions on the following?
>>
>> assert(only httpd uses apr LDAP)
>>
>
> Can you cite references to show this is so? I would be very hard pressed to
> assert that functionality that has been a
On 24.03.2009 12:33, Graham Leggett wrote:
> Jeff Trawick wrote:
>
>> any counter-knowledge/opinions on the following?
>>
>> assert(only httpd uses apr LDAP)
>
> Can you cite references to show this is so? I would be very hard pressed
> to assert that functionality that has been available in APR
On Tue, Mar 24, 2009 at 12:39 PM, Graham Leggett wrote:
> Justin Erenkrantz wrote:
>
>> Of course not, that's why I posted.
>>
>> The clear consensus here in the room is that the current approach to
>> LDAP is broken and ill thought-out (for the reasons I illuminated),
>> but what there isn't cons
Justin Erenkrantz wrote:
Of course not, that's why I posted.
The clear consensus here in the room is that the current approach to
LDAP is broken and ill thought-out (for the reasons I illuminated),
but what there isn't consensus on is how to proceed. Hence, the
discussion on-list about how to
On Mar 24, 2009, at 6:46 AM, Justin Erenkrantz wrote:
On Tue, Mar 24, 2009 at 11:42 AM, Bing Swen wrote:
This is very good for simplifying the updating of the library.
What about apr-iconv? It still has a reduced function set of
libiconv prior to 2000.
When we've brought this up in the pa
Jeff Trawick wrote:
any counter-knowledge/opinions on the following?
assert(only httpd uses apr LDAP)
Can you cite references to show this is so? I would be very hard pressed
to assert that functionality that has been available in APR for many
years would have just one single user.
asser
Justin Erenkrantz wrote:
[ ] Fix the LDAP interface to be a complete/full LDAP abstraction
[X] Remove the LDAP interfaces from APR
Regards
--
^(TM)
On Tue, Mar 24, 2009 at 11:52 AM, Graham Leggett wrote:
> Development of APR doesn't happen via conversations in Amsterdam.
Of course not, that's why I posted.
The clear consensus here in the room is that the current approach to
LDAP is broken and ill thought-out (for the reasons I illuminated),
Justin Erenkrantz wrote:
So, during the conversations we've had here in Amsterdam regarding
combining APR and APR-util (see post from Paul), one of the big
stumbling blocks has been our treatment of the LDAP interfaces via
APR-util.
The crux of the issue is that it is a 'leaky' abstraction - in
On Tue, Mar 24, 2009 at 11:42 AM, Bing Swen wrote:
> This is very good for simplifying the updating of the library.
> What about apr-iconv? It still has a reduced function set of libiconv prior
> to 2000.
When we've brought this up in the past, I believe we felt that
apr-iconv should continue to
"Paul Querna" wrote on Tuesday, March 24, 2009 6:22 PM
>
>In the short term, we would like to merge the two libraries, into one
> monolithic giant APR 2 library.
This is very good for simplifying the updating of the library.
What about apr-iconv? It still has a reduced function set of libiconv
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
wrote:
> So, during the conversations we've had here in Amsterdam regarding
> combining APR and APR-util (see post from Paul), one of the big
> stumbling blocks has been our treatment of the LDAP interfaces via
> APR-util.
>
> The crux of the iss
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
wrote:
> Therefore, the consensus of the folks here is that we should pursue
> one of the following courses of action:
>
> [ ] Fix the LDAP interface to be a complete/full LDAP abstraction
> [X] Remove the LDAP interfaces from APR
It belongs in
So, during the conversations we've had here in Amsterdam regarding
combining APR and APR-util (see post from Paul), one of the big
stumbling blocks has been our treatment of the LDAP interfaces via
APR-util.
The crux of the issue is that it is a 'leaky' abstraction - in that,
APR-util does not cur
Hi,
At ApacheCon, we have had a discussion about APR 2.x and APR-Util.
In the short term, we would like to merge the two libraries, into one
monolithic giant APR 2 library.
In the long term, we would like to split out things that add extra
dependencies to their own sub-libraries.
What I am star
41 matches
Mail list logo
