From: h1suzuki@Bridgew.edu (Hideaki Suzuki)
Subject: [b-free 748] Re: 仮身名
Date: Wed, 08 Oct 97 18:56:23 -0500
> ども。Aki です。
>
>
> |From: h1suzuki@Bridgew.edu (Hideaki Suzuki)
> |Subject: [b-free 728] Re: 仮身名
> |Date: Fri, 03 Oct 97 07:07:27 -0500
> |
> |> |1)長い実身名は勧められない。
> |> |2)だからサポートするのは短い実身名でよい。
> |> |3)しかし、長い実身名を使いたいときのために
> |> | 「良い方法」をサポートしておくとよい。
> |> |4)例えば長い名前を使うのだから手間のかかる
> |> | 方法ではどうか。
> |>
> |> 正確だと思います。
> |> それでも、長い実身名をどうしても利用者が使いたいなら、それは仕方がない。
> 利用
> |> 者が Cost を負ってくれないか、という訳です。
> |
> |これだけはやめて欲しいことが、ひとつだけあります。
> |それは、ユーザからの見た目には連続に見える長い実身名を
> |切り刻んで、なんらかの方法でシステムが保持することです。
> |そりゃーまさしく、Windows95 の VFAT です。
> |あんな brain-damaged なファイルシステムは願い下げです。
>
> たとえば、通常の入力は「一行入力パネル」から行い、ある程度以上の情報の入力は
> 「長文用の入力パネル」から行うとか。
> で、ユーザーからの見た目は連続ではなくなりますが。まあ、それでも、仮身上の表
> 示は連続なのかな。そだ。仮身上でも、どう表示すべきかは問題だ(短い物と長い物
> の表示方法が不連続になるのかどうか)
話のレベルが違うのでは?
UI とファイルシステムの内部構造の話は同列には論じられないですよ。
で、どうして「一行入力パネル」と「長い入力パネル」を分ける必要があるの
でしょうか?
> それをさておいても、確かに不連続なのは、滑稽ですね。それは同意します。フラッ
> トがいつも一番。メモリモデルもフラットが楽。互換性に縛られてなんでも切り刻ん
> できたのが、Wintel の選んだ手段ですね。
>
> ただ、1Bファイルシステムへの互換性との兼ね合いを考えるときに、(やっぱり)
> 他によい方法が見あたらないのです。その上、非常に大量の実身名は入力頻度が低い
> と(hopefuly)思われるので、短い実身名は簡単に入力できて、長い実身名だと大変と
> いうのは別に悪い方法ではないと思います。
>
> # 長い実身名は「気合いを入れてから」入力するから、
> # 気合いを入れる分、始めるのに手順があってもいいと云う事ね。
うーん。
あらかじめ名前をつける時に長いか短いかを意識するということですか?
カットアンドペーストを許す場合など、長いということを意識しないことも
あると思います。長い文字列を実身名の入力パネルにペーストするときに、
いちいち意識するのは面倒くさいと思いませんか?
もっとも、UI の問題については、長い実身名をサポートするかどうかの
議論としては、あまり意味がないことだと思います。
なぜかというと、長い実身名をサポートした OS の上で動く UI は、それ
なりに長い実身名をサポートしたものを作ることになると思うからです。つま
り、短い実身名をサポートしただけの現在の 1B などの UI を前提にする
必要はないと思います。
> この辺はどちらにしろ、しっかり、詰める必要があることでしょう。
>
> 1 1Bとの互換性をどう取るのか。(諦めて良いのか)
1B (のファイルシステム?)との互換は、BTRON1 ファイルシステムで取れば
いいのでは?
いくらなんでも、1B からそのまま読めることを B-Free OS の独自ファイルシ
ステムで保証する必要はないでしょう。
> 2 UI をどう取るのか。(不連続かどうか)
私の考えでは、実身名の指定をするときにいちいち長いか短いかを意識する
のは面倒なのでひとつに統一すべきだと思います。
(「えーと、実身名が 101 文字だから、これは長いな。じゃ、長い実身名を
入力するパネルを出して、と。こちらは、99 文字だから、短い実身名を
そのまま入力すればいいな。ラッキー☆ 」
。。。 なんていうことをするのは、私は御免です)
> 3 内部形式をどう取るのか。(実装で互換性を考慮するのか)
>
> 僕も、どうしたらよいのか、よく分かっていない。<あたりまえだが。
> どちらにしても、結論は、次の meeting で1Bの資料が提出されるまでは少なくと
> も出ないだろうけど。
>
>
>
> # 要するに、一番困るのは3Bの仕様が出てこないことか?! (暴言2)
3B のファイルシステムは 1B 互換だと思うので、BTRON1 プログラミングハン
ドブックのままにインプメントすればいいと思いますけど。
(あくまで BTRON1 ファイルシステムについては、です)
> |長い実身名をつけさせないようにするためには、
> |長い実身名をつけたくなくなるような、「ユーザインタフェース」を
> |提供すればいいのであって、実装の方は、
> |非常に簡単に扱えるようになっていてもいいのです
> |というか、そのほうがプログラムが一貫していいでしょう。
> |
> |というわけで、長いファイル名が「付けられる」という時点で、
> |実装は、短いファイル名でも、長いファイル名でも、
> |違いのないシステムを採用すべきだと考えます。
> |
>
> というわけで互換性の事をどうするかで、「長い名前」をフラットに実装するか増改
> 築的に実装するかがきまると思います。まあ、ぼくは API がフラットだとして処理
> すれば、記録方法は増改築的でも良いのだけど。
ううむ、「記録方法は増改築的でも良いのだけど。」というのは、そのまま
VFAT のような記録方式でもいいということですか?
むしろ、長い仮身名をサポートするならば、内部構造が異なった新しいファイル
システムをサポートする方がいいと思います。
>
> # さらに、長さの度合いにも実装方法は(もちろん)依存。
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d