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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
