perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Apache::Util porting issues
Date Fri, 25 Jan 2002 08:16:30 GMT
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:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/


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


Mime
View raw message