httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [apreq-2] does not use apr-config --includes
Date Mon, 18 Aug 2003 07:33:10 GMT
Joe Schaefer wrote:
> Stas Bekman <> 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 [*] instead) 
>   apr_table_add         (use addn with [*] instead)
>   apr_table_merge(n)    (don't use these, ever)
>   apr_table_overlap     (don't use with APR_OVERLAP_TABLES_MERGE)
>   [*]- is the "data" attribute of an apreq_value_t

Ah, I forgot about the C API. In that case we probably need to use apreq_?

>>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.

As long as the user interface doesn't change, I suppose that it doesn't matter 
at this point how the guts are implemented.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message