Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 08 Sep 2001 17:22:08 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: [PATCH] Turn apr_table_t into a hash table
To: dev@httpd.apache.org
Cc: dev@apr.apache.org
Message-id: <3B9AB630.4090309@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
References: <3B993AEB.8040602@pacbell.net>
 <20010908214046.5CA0F46DF4@koj.rkbloom.net> <3B9A9AD9.1010205@pacbell.net>
 <20010908235443.9A6AB46DF4@koj.rkbloom.net>

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