apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Comstock <st...@trainersfriend.com>
Subject Re: SCons Updates... 2
Date Fri, 23 Jan 2009 14:37:40 GMT
Dan Poirier wrote:
> Greg Stein <gstein@gmail.com> writes:
> 
>> Understood. But if you're writing new code (for APR 2.x), then why
>> wouldn't you develop the codebase in Unicode? "Link with old
>> libraries" might be an answer, though I'd say "it is outside the scope
>> of APR to interact with that old library".
>>
>> Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
>> encoded as UTF-8 across the board.
>>
>> I'm not disputing that EBCDIC is still in use (as you eminently point
>> out). Just that I fail to see it has a strict, useful requirement for
>> APR 2.x.
> 
> Frankly, internal Unicode would be great.  Just so input and output
> still support EBCDIC, since people still do use it.  (Maybe even just
> input - does anyone actually serve web pages in EBCDIC?)

Well, I was just going to lurk, but I believe the answer
to this question is No. The z/OS servers convert EBCDIC
strings to UTF-8 by default. I don't think many (any?)
browsers support EBCDIC.


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

   z/OS Application development made easier
     * Our classes include
        + How things work
        + Programming examples with realistic applications
        + Starter / skeleton code
        + Complete working programs
        + Useful utilities and subroutines
        + Tips and techniques

==> Check out the Trainer's Friend Store to purchase z/OS  <==
==> application developer toolkits. Sample code in four    <==
==> programming languages, JCL to Assemble or compile,     <==
==> bind and test.                                         <==
==>   http://www.trainersfriend.com/TTFStore/index.html    <==

Mime
View raw message