perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angus Lees <...@inodes.org>
Subject Re: Embperl 2.0?
Date Mon, 02 Jun 2003 21:58:21 GMT
At Mon, 2 Jun 2003 10:28:24 +0200, Kaare Rasmussen wrote:
> Any news about the release date of 2.0?

I obviously can't speak for Gerald, but I know of two outstanding
issues:

 "make test" doesn't succeed (fails in various ways) on some non-i386
 archs (alpha, m68k, ia64, arm). There's some 32/64 bit or endian
 issues somewhere I haven't tracked down yet (haven't looked
 recently - its proving hard to track down).

 Non-latin1 encodings aren't dealt with nearly as well as they could
 be. (big, but should be addressed at some point)


Afaics, the "right" thing to do with file encodings is to:

 get the input encoding (as an Execute arg, from HTML meta or XML
 encoding), use perl5.8 "encoding" pragma to get perl code blocks
 converted correctly.

 on output, convert to desired output encoding (which defaults to
 input encoding).  If output encoding is not the same as input
 encoding, text chunks will need to be reencoded.

 Perl output needs to be reencoded from utf8.  Characters that don't
 fit into the new encoding need to be escaped appropriately - this
 should be a hook into the Syntax (output escaping should be too), but
 its probably ok to only hardcode HTML and XML.

 HTML encoding headers / XML declaration needs to include correct
 output encoding.

 Cached output needs to be tagged with encoding too.  Reencoding
 cached output is most likely much cheaper than reproducing it, so we
 might want to cache multiple encoded versions or only cache the most
 recent encoding or something.

IMO, its acceptable to only support all this on perl5.8, possibly
using Encode or iconv(3).

Of course I'm probably never going to get around to coding it, so its
all just wishful thinking :(


On a lighter note, saw a talk last week at my local LUG by one of the
squid developers.  Squid 3.0 will feature an "Edge Server Includes"
implementation (think akamai), and it sounds almost trivial to get
Embperl::Object to support it (you basically offload the component
assembly step to squid) - should anyone want this level of
scalability.

-- 
 - Gus

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


Mime
View raw message