Date: Thu, 6 Jun 1996 15:13:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: DARREND@novell.com (Darren Davis) Cc: michaelv@HeadCandy.com, terry@lambert.org, hackers@freebsd.org Subject: Re: Breaking ffs - speed enhancement? - Reply Message-ID: <199606062213.PAA02008@phaeton.artisoft.com> In-Reply-To: <s1b6edb6.001@fromGW> from "Darren Davis" at Jun 6, 96 02:49:17 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Gee, sounds like multiple name spaces to me. Now where have I heard that
> one? {:-)
It's tiered multiple name spaces.
This is very different from what Novell let me do with the attributed
FS for the NWU product on UnixWare, if that's where you think you
heard it. 8-).
It's also different from the Native NetWare FS code, since in a
Native NetWare volume, file names are file attributes, like
permissions... this is kind of antithetical to the UNIX model,
even though it (sorta) supports multiple names for a file.
What I'm talking about is localization enabling: localization to a
single locale. Jay Eckstrom's group (the advanced file system design
group in the Novell Server Products Division) were more interested
in having multiple locales simultaneously... though never interested
enough to add Unicode support, it seems. 8-).
It's a different problem: Jay's problem is one of dealing with multiple
client machine "code pages". It's a DOS-centric problem, and it's
a problem primarily because of memory restrictions on Legacy DOS
clients not permitting the page translation to occur on the clients
(gotta keep those 640k people happy, don't ya know!).
I remember when Jay started talking about "distributed replicated
block stores" -- what Drew called "block smearing"... I was the
one who sent them the ZEBRA papers, showing that what they wanted
had been implemented, with so-so results, more than two years before.
I think everyone is (incorrectly) trying to solve the multinationalization
problem in the context of the client. This seems (to me) to be the
wrong thing to do.
It's kind of silly to translate characters from the server into an
English name *on the server* to help those hapless code page 435
clients, instead of making the client deal with Unicode, and
implementing the round-tripping there.
It doesn't matter if the name is unprintable because the round trip
character set is munged through a code page, or through an ISO 8859-1
font, or through some other round-trip-standard. You aren't going
to be reading Japanese documents with English names, typically, in
any case. If you can't support the name display, you can't support
the content display. 8-).
"Well known files and directories" should be referenced by ID instead
of name by "Well known file and directory referencing programs".
Pretty simple idea.
It's the rare "Tamil" to "Cantonese" translator who will be translating
in the context of a single round trip character set instead of doing
the translation in the context of a multinationalized tool. Such
tools are special case constructs, useful only to translators or
linguistic scholars (even amatuer ones, like myself 8-)). The
general case for localization is one machine and one locale, or one
back-end-store (file system or file server) and Unicode.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606062213.PAA02008>