Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: [apreq-2] does not use apr-config --includes
Date: 17 Aug 2003 16:23:49 -0400
Lines: 30
Message-ID: <m3ptj4ghii.fsf@sol.sunstarsys.com>
References: <1060191816.9071.19.camel@eric> <3F3E6B3E.5070806@stason.org>
 <m33cg1igm3.fsf@sol.sunstarsys.com> <3F3E7F1A.7@stason.org>
 <m3y8xtgy54.fsf@sol.sunstarsys.com> <3F3E9626.4040603@stason.org>
 <m3u18hgv1y.fsf@sol.sunstarsys.com> <3F3F2008.50506@stason.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Sender: news <news@sea.gmane.org>

Stas Bekman <stas@stason.org> writes:

[...]

> I suppose it depends. If you are satisfied with the current
> implementation of apr_tables and you think that you won't need even
> more control and flexibility in the future, 

People that use the C API directly would need to be cautioned 
against using

  apr_table_set         (use setn with v.data [*] instead) 
  apr_table_add         (use addn with v.data [*] instead)
  apr_table_merge(n)    (don't use these, ever)
  apr_table_overlap     (don't use with APR_OVERLAP_TABLES_MERGE)

  [*]- v.data is the "data" attribute of an apreq_value_t

> it's probably ok to leave apreq_tables behind. In any case I suppose
> that if you ever need that control you will be able to replace
> apr_tables with apreq_tables, since that won't change the user's
> API. However it's probably safer to use a different class:
> ApReq::Table since if you change the behavior of APR::Table,

If we go back to apreq_tables, we *must* drop APR::Table 
as the base class for our Perl tables: Apache::Request::Table, 
Apache::Upload::Table, and Apache::Cookie::Table.

-- 
Joe Schaefer