httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apreq-2] does not use apr-config --includes
Date Mon, 18 Aug 2003 07:33:10 GMT
Joe Schaefer wrote:
> 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

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
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message