Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 08 Sep 2001 15:25:29 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: Re: [PATCH] Turn apr_table_t into a hash table
To: rbb@covalent.net
Cc: dev@httpd.apache.org, dev@apr.apache.org
Message-id: <3B9A9AD9.1010205@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>
 <20010908202001.2EE4646DF4@koj.rkbloom.net> <3B9A84BA.7070607@pacbell.net>
 <20010908214046.5CA0F46DF4@koj.rkbloom.net>

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.

>>> 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?
>
mod_perl and Tomcat (mod_jk) don't use apr_table_elts.  PHP contains two 
calls to it.

>  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.
>
Based on how infrequently apr_table_elts is used in the core and in PHP and
mod_perl, and how small the code change required to use the iterator API is,
I'd be extremely surprised if the removal of apr_table_elts substantially
impaired one's ability to port a module from 1.3 to 2.0 in under an hour.

--Brian