Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Cc: dev@apr.apache.org
Message-Id: <70518EE8-1625-4E5D-8EF7-D88324559431@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: "William A. Rowe Jr." <wrowe@rowe-clan.net>
In-Reply-To: <4DA7A0DD.5090506@rowe-clan.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: planning to T&R apr-util 1.3.11 later today
Date: Fri, 15 Apr 2011 10:17:03 +0200
References: <BANLkTiktkXreyN-=Z6zPNK-6Wx8FS_avHg@mail.gmail.com>
 <4DA726B3.4090407@rowe-clan.net>
 <2532D115-2BBE-4276-AEB7-DC339D9CF657@sharp.fm>
 <4DA7A0DD.5090506@rowe-clan.net>

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
--