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
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
On Tue, Mar 24, 2009 at 11:26 AM, Justin Erenkrantz
jus...@erenkrantz.com 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
Paul Querna p...@querna.org 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
On Tue, Mar 24, 2009 at 11:42 AM, Bing Swen bs...@pku.edu.cn 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
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 -
On Tue, Mar 24, 2009 at 11:52 AM, Graham Leggett minf...@sharp.fm 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
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.
On Mar 24, 2009, at 6:46 AM, Justin Erenkrantz wrote:
On Tue, Mar 24, 2009 at 11:42 AM, Bing Swen bs...@pku.edu.cn 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
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 Tue, Mar 24, 2009 at 12:39 PM, Graham Leggett minf...@sharp.fm 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
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 for many
On Tue, Mar 24, 2009 at 12:33 PM, Graham Leggett minf...@sharp.fm 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
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
Bing Swen wrote:
Paul Querna p...@querna.org 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
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
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 their own
[ ] Fix the LDAP interface to be a complete/full LDAP abstraction
[X] Remove the LDAP interfaces from APR
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
On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett minf...@sharp.fm 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
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
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
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
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
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
On 3/24/2009 at 4:26 AM, in message
5c902b9e0903240326r3222ac90k15dcb7f34d2d1...@mail.gmail.com, Justin
Erenkrantz jus...@erenkrantz.com 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
On 3/24/2009 at 7:47 AM, in message
4239a4320903240647x12f09613l6eb58974cd656...@mail.gmail.com, Paul Querna
p...@querna.org wrote:
On Tue, Mar 24, 2009 at 2:23 PM, Graham Leggett minf...@sharp.fm wrote:
William A. Rowe, Jr. wrote:
We've actually discussed this on list for several years, and
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
dbd
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
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
dbd
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 -
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])
buckets -
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:
...
What's the
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
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 hard
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:
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
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
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
39 matches
Mail list logo
