Ryan Bloom wrote:
On Saturday 08 September 2001 15:25, Brian Pane wrote:
Ryan Bloom wrote:
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.\
Yes, macro wrappers would work. But if we use that approach, it would be advantageous to use macro names like "apr_table_get" so that all the existing httpd code and 3rd party modules can be used without modification. This would be functionally equivalent to the "implement apr_table_t using apr_hash_t" approach that I prefer.
That would make tables a hash again, which is what I disagree with. Yes, creating a new API will require module authors to modify their code to take advantage of the hash table performance. But, it keeps the table API refering to tables, instead of hashes. This will also require more modifications to httpd, but in the end, it keeps the code easier to read and understand.
To me, a table, even if implemented using apr_hash_t, is different from an apr_hash_t. The apr_table_t, as it's been used in the httpd, isn't a general-purpose set-of-strings. Rather, it's a set-of-strings-with-special- support-for-concatenation-and-merging-that-works-well-for-http-headers. Operations that are essential on tables, like apr_table_merge() and the corresponding support in apr_table_overlap(), don't make sense for the general-purpose, type-neutral apr_hash_t.
I'm also opposed to having a declaration like:
apr_hash_t *headers_in;
apr_hash_t *headers_out;
in the request_rec. Architecturally, those objects need to be unordered sets with
fast access and the aforementioned merge support. They don't need to be hash tables
specifically. The implementation could just as well be a balanced tree; all the code
in the httpd that uses the httpd shouldn't know or care about how the "unordered set"
object is implemented.
--Brian
