apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject apr-iconv 1.0
Date Wed, 23 Jun 2004 19:35:11 GMT
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they
are seperate subsets with their own set of issues.

APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
So no holdup of David's plans.

I'm proposing we switch around apr-iconv's interface to:

1) change typedef void *apr_icon_t; to an incomplete type, e.g.
   typedef struct apr_icon_t apr_icon_t; 

2) consistently use an apr_icon_t * or (for create) apr_icon_t **
   as the arguments to the exposed functions.

3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder
   as the first not last arg, consistent with apr.

4) drop apr_pool_t argument from _close, that should use the same pool 
   as the associated _open.

I'm not suggesting using the apr_iconv_open()ed pool for xlate operations,
those may be in a frequently recycled pool, as oppsed to a long lived
pool used for apr_iconv_open (_close).

Of course, the apr_pool_t *p becomes a member of our internal apr_iconv_t
structure.

Thoughts?

Bill


Mime
View raw message