Date: Mon, 19 Jan 1998 22:13:02 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Terry Lambert <tlambert@primenet.com> Cc: daniel_sobral@voga.com.br, hackers@FreeBSD.ORG Subject: Re: Wide characters on tcp connections Message-ID: <199801200313.WAA20726@whizzo.TransSys.COM> In-Reply-To: Your message of "Mon, 19 Jan 1998 19:37:06 GMT." <199801191937.MAA05333@usr08.primenet.com> References: <199801191937.MAA05333@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This is similar to asking if the UNIX filesystem has provisions
> > > for storing "wide characters in files"; the FS doesn't care
> > > what's inside it's files.
> >
> > Though that's technically right, one might feel the need for a standard if
> > the files he writes are going to be read by other people's programs. Of
> > course TCP, by itself, provides all support you need to send the
> > characters, but ignoring the practical problems would be akin to keeping to
> > IP (vs TCP or UDP) because that's all you _really_ need...
>
> The issue is one of stream synchronization. This is my main problem
> with UTF over non-error-checked links. If you have an implicit value
> boundry, then you are guaranteed a synchronized stream.
Not applicable. TCP *is* an error checked link. Absent application
implementation errors, you shouldn't get unscynchronized.
> Re: the FS example: a better example is to perhaps ask if a UNIX
> FS has provisions for storing "wide characters" (or preferrably,
> 16bit wchar_t values from ISO10646 aka Unicode) in *directory
> entries* (the current answer is "no, namei is too stupid").
Why is this a better example? It's not like we're trying to name
transport endpoints with any sort of character strings; the issue
is "awareness" of the underlying {transport,storage} mechansim.
There's really no point in reimplementing a transport protocol given
the literally thousands of man-hours of work by a lot of clever
people over more than a decade to make TCP work well.
louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801200313.WAA20726>