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?)
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?
-----
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);
-----
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)?
or should ht_time be just like in APR and compat.pm to have the old
function in pure perl?
----
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.
----
Is this a correct mapping?
- escape_uri => ap_os_escape_path (needs pool!)
shouldn't it be ap_escape_url?
- 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.
also should we introduce these: ap_escape_path_segment, ap_escape_url
----
- 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.
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)
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?
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?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
