apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
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 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 Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message