You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Graham Leggett <mi...@sharp.fm> on 2011/05/15 16:33:18 UTC
Re: planning to T&R apr-util 1.3.11 later today
On 15 Apr 2011, at 3:38 AM, William A. Rowe Jr. wrote:
> Guessing you are catching up on list traffic sequentially and you'll
> note that
> Jeff clarified this wasn't about apr-util 1.4 at all. Presuming we
> want some
> apr-util 1.4/1.5, I'll get the review done shortly against *trunk*
> anticipating
> that we will replace apr_crypto before any official apr project
> release, if that
> works for you?
All the changes in your laundry list that hadn't already been done on
trunk have now been applied to trunk, most specifically the reordering
of the parameters and the removal of apr_crypto_t where
apr_crypto_block_t was already present in the API call. Apart from
whitespace and comments, your previously posted apr_crypto.h and apr
v2.0's apr_crypto.h are now identical.
Next step will be to backport the current apr v2.0 API to v1.4, so
that there is just one common API in v2.0 and v1.4, which will in
theory remove any blockers we currently have over releasing apr-util
v1.4.
Does this plan make sense?
Regards,
Graham
--
Re: planning to T&R apr-util 1.3.11 later today
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/15/2011 11:36 PM, Graham Leggett wrote:
> On 16 May 2011, at 12:15 AM, William A. Rowe Jr. wrote:
>
>>> All the changes in your laundry list that hadn't already been done on trunk have now been
>>> applied to trunk, most specifically the reordering of the parameters and the removal of
>>> apr_crypto_t where apr_crypto_block_t was already present in the API call. Apart from
>>> whitespace and comments, your previously posted apr_crypto.h and apr v2.0's apr_crypto.h
>>> are now identical.
>>
>> Coolio!!! Looking at this now.
>
> apr_dbd is next up once apr_crypto is baked, the thinking was to add #ifdefs to mod_dbd
> and friends to compile with both apr v2.0 and apr-util v1.4 the same way we do on
> mod_session_crypto now, not sure your thoughts on that? Alternatively we can wait till
> httpd v2.4 is out the door before doing this.
Yea, that could wait a bit; there will be a host of small fixes.
We might even need to consider two namespaces, and offering the old symbols
in an apu_util_compat.h for the short term.
Re: planning to T&R apr-util 1.3.11 later today
Posted by Graham Leggett <mi...@sharp.fm>.
On 16 May 2011, at 12:15 AM, William A. Rowe Jr. wrote:
>> All the changes in your laundry list that hadn't already been done
>> on trunk have now been
>> applied to trunk, most specifically the reordering of the
>> parameters and the removal of
>> apr_crypto_t where apr_crypto_block_t was already present in the
>> API call. Apart from
>> whitespace and comments, your previously posted apr_crypto.h and
>> apr v2.0's apr_crypto.h
>> are now identical.
>
> Coolio!!! Looking at this now.
apr_dbd is next up once apr_crypto is baked, the thinking was to add
#ifdefs to mod_dbd and friends to compile with both apr v2.0 and apr-
util v1.4 the same way we do on mod_session_crypto now, not sure your
thoughts on that? Alternatively we can wait till httpd v2.4 is out the
door before doing this.
Regards,
Graham
--
Re: planning to T&R apr-util 1.3.11 later today
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/15/2011 3:33 PM, Graham Leggett wrote:
> On 15 Apr 2011, at 3:38 AM, William A. Rowe Jr. wrote:
>
>> Guessing you are catching up on list traffic sequentially and you'll note that
>> Jeff clarified this wasn't about apr-util 1.4 at all. Presuming we want some
>> apr-util 1.4/1.5, I'll get the review done shortly against *trunk* anticipating
>> that we will replace apr_crypto before any official apr project release, if that
>> works for you?
>
> All the changes in your laundry list that hadn't already been done on trunk have now been
> applied to trunk, most specifically the reordering of the parameters and the removal of
> apr_crypto_t where apr_crypto_block_t was already present in the API call. Apart from
> whitespace and comments, your previously posted apr_crypto.h and apr v2.0's apr_crypto.h
> are now identical.
Coolio!!! Looking at this now.
> Next step will be to backport the current apr v2.0 API to v1.4, so that there is just one
> common API in v2.0 and v1.4, which will in theory remove any blockers we currently have
> over releasing apr-util v1.4.
>
> Does this plan make sense?
Yes, that sounds like the plan, we just have to go back to the recent
vote thread to determine if this is 1.4.0, or 1.4.1, or 1.5.0.