perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: Apache::Util porting issues
Date Fri, 25 Jan 2002 18:05:21 GMT
On Fri, 25 Jan 2002, Stas Bekman wrote:

> I've started porting Apache::Util, here is a summary of issues:
> 
> Now we have ModPerl::Util as well, so is this the right mapping:
> 
> ModPerl::Util:
> --------------
> - untaint
> - exit
> - size_string (has nothing to do with Apache
>                 or should it stay in Apache::Util?)

it used to be a string version of ap_send_size(), which no longer exists
in favor of the new apr_strfsize() function.  we should use that in 2.0
and add a compat wrapper for Apache::Util::size_string.
 
> Apache::Util:
> -------------
> - escape_uri
> - unescape_uri
> - unescape_uri_info
> - escape_html
> - parsedate
> - ht_time           (=> ap_ht_time)
> - validate_password (=> apr_password_validate)
> 
> -----
> if we move some functions from Apache::Util as in 1.x to
> ModPerl::Util, we need to fix these up in compat.pm, right?

in general we should keep the 2.0 version as close to the C functions as
possible, in terms of names and arguments, including those that take a
pool.  then add compat.pm wrappers around the ones that have changed.

> -----
> 
> Apache::Util has @EXPORT_OK for its all functions, should we keep it that
> way? If so should I create xs/Apache/Util/Util_pm with:
> 
> use Exporter ();
> @EXPORT_OK = qw(escape_html escape_uri unescape_uri unescape_uri_info
> 		parsedate ht_time size_string validate_password);
> %EXPORT_TAGS = (all => \@EXPORT_OK);

let's get all the new functions and wrappers written first, then figure
out which exports belong in Apache::Util and which should be in compat.pm
 
> -----
> 
> ht_time()'s API is not compatible with Apache::Util::ht_time with 1.x,
> we cannot provide a fast wrapper since it now requires a pool object.
> so should the code from 1.x be ported without going into APR land (no
> pool required)?

1.x ht_time also requires a pool, we used the util_pool() function
underneath.  in 2.0 we should be able to optionally pass in a pool,
defaulting to something for compat.  either that or move ht_time to a new
package (like Apache::{Date|Time}) that require a pool argument and then
compat.pm has the Apache::Util::ht_time wrapper with default pool.
 
> parsedate(). Should we use
> 
>    APU_DECLARE(apr_time_t) apr_date_parse_http(const char *date);
> 
> but it seem to return microsecs, so need to adjust this.
> 
> should it move into APR::Date now, with compat.pm adjusting for this
> change. Or should we just drop the parsedate() name (and still have it
> in compat.pm) and start using date_parse_http()?
> 
> also we have a new apr_date_parse_rfc in apr_functions.map, if we
> expose it (we already do) it makes sense that date_parse_http will be
> there too.

yes, those should go in APR::Date
 
> ----
> 
> Is this a correct mapping?
> 
> - escape_uri          => ap_os_escape_path (needs pool!)
>           shouldn't it be    ap_escape_url?

same as 1.x, apache has (in both 1.x and 2.0) #define ap_escape_uri
 
> - unescape_uri        => ap_unescape_url
> 
> - unescape_uri_info   => port XS from Apache.xs in 1.x
> 
> should they still be called _uri or renamed to _url per ap_ functions?
> in todo/api.txt, you say:
> 
>    Apache->unescape_url{_info}:
>    not yet implemented.  should be moved to Apache::Util
> 
> you call these _url, not _uri.

i guess there is confusion because apache has:
#define ap_escape_uri
and
int ap_unescape_url

i don't care which we use so long as there is compat somewhere.
 
> also should we introduce these: ap_escape_path_segment, ap_escape_url

don't know what ap_escape_path_segment does.  there is no ap_escape_url,
just the #define ap_escape_uri.  dunno if it should be renamed or not.
 
> ----
> 
> - escape_html         => ap_escape_html (needs pool!)
> 
> First of all what are we going to do about the issues raised by Robin
> Berjon in the recent thread? I'm talking about UTF encodings not being
> escaped.

haven't read that.  but i hope this would be handled in apache and not
special by us.
 
> Second, what to do with the functions requiring a pool object? todo
> says:
> 
>    also need to default to current pool (pconf at startup, r->pool at
>    request time)

the 2.0 functions should take an APR::Pool argument.

> but the 1.x API, doesn't have $r in the API. Can we have some global
> variable that always points to the current pool? in the order r->pool,
> s->pool, or pconf? This will solve many API adjustments problems. Or
> s->is it a bad idea?

we should avoid that whenever possible.  but we could change
modperl_sv2pool to allow &PL_sv_undef which means use
modperl_global_request_rec_get()->pool if available else
modperl_global_get_pconf()
 
> Third, todo/api.txt says:
> 
>    enhancements: consider jeff baker's more robust implementation of
>    my_escape_html(), which should probably be made in apache-2.0 itself
> 
> where is it? is it utf compliant?

i don't remember, ask jeff.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message