[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: newlines and code page conversion
From: |
Terrence Enger |
Subject: |
Re: newlines and code page conversion |
Date: |
Tue, 13 May 2003 21:18:32 -0400 |
At 18:12 2003-05-13 -0400, Ross Patterson wrote:
>On Tuesday 13 May 2003 05:25 pm, Terrence Enger wrote:
>> As part of my
>> changes I am replacing literal '\012' in the source code by '\n' and then
>> making the program explicitly transate to/from ASCII for the client/server
>> socket communications.
>
>I hope you're not talking about changing the over-the-wire protocol, that
>would be "bad". As would performing wholesale ASCII-EBCDIC translation on
>the connection data (think about binary files - are they shipped as binary
or
>encoded somehow, and if so is it safely translatable?). Of course, if
you've
>tried doing any kind of network programming in an EBCDIC world before, this
>is old news to you. As is the advice to make the code page ids configurable.
No, I do not plan to change the over-the-wire protocol. (We ECDICers are
great people, but we are too few to take over the world <grin>.)
All I was talking about here is the way the source code expresses the string
and character constants with which the program controls the protocol. The
ASCII-EBCDIC translation is of narrower interest. If the translation is ever
taken into the official source at all, I think it needs to be conditioned by
"compatibility cruft".
As for transferring binary files ... Well, I have been trying not to think
ahead to that. My hope is that the way will become clearer as I become more
familiar with the code.
I shall have to think about configurable code page ids. I could be coming
back with more questions!
>
>> Particularly, does anyone know of a platform where this would cause
>> problems?
>
>I've never examined the wire-line protocol, but CVS normalizes the MS-DOS
CRLF
>linends to the Unix LF (aka \n) someplace, probably on the client side.
Indeed, I would like to make code page issues as unobtrusive to the user as
differences in line endings are now. It remains to be seen how close I can
come to that.
>
>> Thank you all for your attention and thoughts.
>
>Hey, it's an ASCII world out there, we EBCDICers (ex-VMer in my case) need
to
>band together :-)
Thank you for your help.
>--
>Ross A. Patterson
>Chief Technology Officer
>CatchFIRE Systems, Inc.
>5885 Trinity Parkway, Suite 220
>Centreville, VA 20120
>(703) 563-4164
>
>
>