On 15 Apr 2011, at 3:35 AM, William A. Rowe Jr. wrote:
I ran a diff from your proposed header against the apr_crypto
header on apr-trunk, and I
notice that you have reinstated the APU_DECLARE macros, when the
apr_trunk code uses
APR_DECLARE, can you explain why you have done this?
Because I'm editing 1.4.x branch? That's probably my first problem,
preparing what
was accomplished already (and compared to what I just re-did in 1.x
branch, /sigh)
for backport and adjusted in httpd 2.3 modules, if any of that
remains to be done for
GA release. Yes, I've surrendered, and am prepared to ignore
whatever apr-unreleased
noise had been emitted by overenthusiastic httpd release processes
over my -1, just
to see this completed. Perhaps we call it apr-util 1.5 and declare
1.4 unreleased
(which it was so far), just to disambiguate.
You may be right, and 2.x trunk may be near perfect w.r.t. both
crypto and dbd, but
what I read in Jeff's post (and what others expressed interest in
recently) is some
release on the 1.x branch. At least unreleased crypto can be made
consistent and
transparent for httpd to build against either 1.x or 2.x apr. Would
you concur?
My plan was have v2.0 reviewed, then backport the changes to apr-util
v1.4.
Given that jim has reviewed it, and you have come up with an API very
similar to the one on trunk, let me conclude that the work so far in
trunk is on the right track at the very least, and let me backport
r899910 this weekend for you from apr-trunk to apr-util v1.4.
My main concern is the relative placement of *this (ctx), **result
and *pool in every
functions' arg list, and I have a whole file of the entire 2.x api
to review mid-May
at the Wicklow f2f, if it isn't finished prior to that gathering.
Are you referring to the order of the parameters? If so, then +1 to
any change that will may the parameters more consistent (given that
the current order is inspired by by apr_dbd). Let me look at that too,
based on the header file you submitted.
Regards,
Graham
--
