httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sat, 08 Sep 2001 21:40:46 GMT

> >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, 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 Bloom
Covalent Technologies

View raw message