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: <2532D115-2BBE-4276-AEB7-DC339D9CF657@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: "William A. Rowe Jr." <wrowe@rowe-clan.net>
In-Reply-To: <4DA726B3.4090407@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 02:19:12 +0200
References: <BANLkTiktkXreyN-=Z6zPNK-6Wx8FS_avHg@mail.gmail.com>
 <4DA726B3.4090407@rowe-clan.net>

On 14 Apr 2011, at 6:54 PM, William A. Rowe Jr. wrote:

> Do you mean, shipping apr_crypto?  Ugh...
>
> I have a laundry list of issues that were never addressed, misfactored
> argument lists, unnecessary function args, pointers to pointers to  
> pointers
> where nested structures would have worked

Please explicitly state which elements of your laundry list were not  
addressed in http://svn.apache.org/viewvc? 
view=revision&revision=899910, so they may be fixed.

Telling everyone "you have a laundry list" is of no use to anybody  
wanting to do the actual laundry.

> - and nobody else has really
> even stepped up with their assessment of the overall design.

http://mail-archives.apache.org/mod_mbox/apr-dev/201102.mbox/%3C2D22F072-7E5E-409D-B2CD-6EEB74FE20A4@jaguNET.com%3E

> I don't
> care if it is missing desired features, but do care if the features  
> that
> are implemented now are poorly thought out.
>
> Essentially, it's a mess.  I understand it is derivative of some  
> related
> design flaws in apr_dbd etc, but that isn't a reason to propagate  
> them.

Can you explicitly state which design flaws from ap_dbd still exist in  
apr_crypto, given that all the design flaws inherited from apr_dbd  
were removed in r899910?

> Attached for your perusal is my very first draft edits of the function
> prototypes

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?

Are you trying to edit apr-trunk, or the apr-util branch?

It looks like you're redoing work that was completed 14 months ago.

For example:

@@ -201,9 +201,9 @@
   * @return APR_EDSOOPEN if DSO driver file can't be opened
   * @return APR_ESYMNOTFOUND if the driver file doesn't contain a  
driver
   */
   * @return APR_EDSOOPEN if DSO driver file can't be opened
   * @return APR_ESYMNOTFOUND if the driver file doesn't contain a  
driver
   */
-APR_DECLARE(apr_status_t) apr_crypto_get_driver(apr_pool_t *pool,  
const char *n
ame,
-        const apr_crypto_driver_t **driver, const apr_array_header_t  
*params,
-        const apu_err_t **result);
+APU_DECLARE(apr_status_t) apr_crypto_get_driver(const  
apr_crypto_driver_t **dri
ver,
+        const char *name, const apr_array_header_t *params, const  
apu_err_t **r
esult,
+        apr_pool_t *pool);

  /**
   * @brief Return the name of the driver.

Regards,
Graham
--