Greg Stein wrote:
On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
...
If not, I still would like to replace apr_table_elts with a different
interface that doesn't make any promises about apr_table_t being
an apr_array_header_t. That will enable us to fix the performance
in later releases without breaking people's application code.
First change is to introduce new APIs to do whatever people were referencing
->nelts or ->elts for. Convert all code to use that, so that the apr_table_t
structure can be opaque.
Once that is done, then we can change the implementation at will, at any
time. And the new APIs must exist anyways.
So... I'd suggest working on the APIs first, and getting code to use them.
*Then* we can look at revamping the table implementation.
The original approach that I posted was a traditional iterator object:
typedef struct apr_table_iter_t apr_table_iter_t;
apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
const apr_table_t *t);
apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
const char **key,
const char **value);
In my experience, this is an easy change to make, at least in the core
modules (I only had to change half a dozen places in httpd-2.0 to get
it to work.)
Does anybody have thoughts for or against this iterator API?
Thanks,
--Brian
