httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [apreq-2] does not use apr-config --includes
Date Sun, 17 Aug 2003 20:23:49 GMT
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


Mime
View raw message