> >The latter. Having two API's to the same functions should only be done
> >as a stop-gap.
>
> I disagree. It's inevitable to have two APIs, as long as we have two
> 'table' types with very different semantics.
>
> apr_table_t is statically typed (uses char*), and apr_hash_t isn't (uses
> void*).
> If we did a direct replacement of apr_table_t with apr_hash_t in the httpd,
> we'd be sacrificing static type-safety for a lot of code.
So create a simple set of prototypes and macros for a char * version of the
hash code, the same way we did for ap_strchr and ap_strchr_c. If you do
that, you will be adding probably two or three new functions to APR.
> > Also, a LOT of modules using the apr_table_elem macro
> >to get the elements from a table. Turning that into an API would break a
> >lot of people.
>
> My patch covers all the changes needed for the core modules. Do you have
> any info on the number of 3rd-party modules for 2.0 that use
> apr_table_elem?
The core is not the only set of modules for Apache. Did you look at mod_perl,
php, tomcat? I don't know if any of them use this feature or not, but they aren't
a part of the core. Did you look at all of the modules in modules.apache.org, or
freshmeat? I know that there aren't many modules for 2.0 today, but at some
point, everybody who has a module for 1.3 will want to port it to 2.0. I can
currently do that in under one hour for even complex modules. Changing API's
like this after we have had 25 releases, makes that harder.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
