In message <199709291035.TAA14749@hisoft.soft.hitachi.co.jp>
"[b-free 686] Re: 仮身名"
"Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
naitoh_r> > TADを使うべきではないというのは、幾つか理由があって
naitoh_r> > ・TADを使うともはや「名」とは言い難い(絵文字を除く)
naitoh_r>
naitoh_r> これは、「名」とは何かという哲学的な命題になってしまいそうなので、
naitoh_r> パス。
(^_^;)
naitoh_r> > ・TADで修飾文字を使うと仮身属性と相性が良くない
naitoh_r>
naitoh_r> これは、アプリケーション側で対処する話なので、どうにでも
naitoh_r> なるのでは?
BTRON1では仮身の表示は「実身仮身マネージャ」の仕事です。
naitoh_r> > ・TADはパス検索を複雑にする
naitoh_r>
naitoh_r> やっぱり、問題はこれかなぁ。
ファイルシステム実装上の大問題ですね。
naitoh_r> > ・文字列はTADではないのでTAD実身名は現在の実身名の拡張でない
naitoh_r>
naitoh_r> えーと、文字列だけだと、もともと拡張にならないのでは?
naitoh_r> 多言語は、TRON 文字コードを使うという話なので、元々の実身名の定義に入っ
naitoh_r> ていますよね?
長さは拡張されますが…。ところで拡張でない(現行のまま)と
なにか問題が?
蛇足ですが、私の言いたいのは、「実身名はTAD」とすると、
管理情報セグメントなどのTADヘッダの入っていない文字列は
TADでないので、TAD実身名は現行の実身名の延長ではない。と
言うことです。
naitoh_r> > ・TADを使うと想像を絶する長さになるかも知れない
naitoh_r>
naitoh_r> これは、適当な制限を入れればいいのでは?
適当な制限値を思い付かないので(^_^;)
naitoh_r> > TAD実身名の対案としては、
naitoh_r> > ・TADを扱える新たな実身属性を作る(名称は?)
naitoh_r> > ・その属性を仮身に表示可能とする(表示非表示は仮身属性で定義)
naitoh_r> > ・実身名として空文字列を許す
naitoh_r> > というものです。これで、この新しい属性はTAD実身名に望まれる
naitoh_r> > 機能を果たすと思います。
naitoh_r> > 追加として
naitoh_r> > ・新しい属性は複数でも良い
naitoh_r> > ・新しい属性を使った検索機能を作る
naitoh_r> > もあげておきます。
naitoh_r>
naitoh_r> むむ。API はどのくらい変更になるんでしょうか?
アドホックには「新しい属性」をサポート(読み書き)するAPI
の追加、仮身属性の追加(リンクレコードが大きくなります)、
実身名に空文字を許すための既存APIの変更(この規模が不明)、
といったところですか。検索するならそのAPIも追加になります。
問題は「実身名に空文字を許す」ですね。基本的にAPIの変更
はいらないと思いますが確認してみないと分からないので。
それより「長い実身名」サポートの方がAPIの変更は大きそう
です。少なくとも読み書きにサイズ情報を付けるようにしない
といけないし、部分アクセスを許すならオフセットも必要だし。
ついでにAPIを前面見直ししてBTRON2風に変えるようにすれば
実身名は単なる属性レコードアクセスだし、「新しい属性」も
属性レコードの追加ですみますけど。
naitoh_r> > naitoh_r> イネーブルウェアなどを考えると音声の情報も入ったファイル名というのは、
naitoh_r> > naitoh_r> 必要としている人はいるでしょう。
naitoh_r> >
naitoh_r> > 普通は、実身名を読み上げる機能があれば十分ですけど。
naitoh_r>
naitoh_r> うーむ。そうなんですか?
個別の実身に音声を埋め込むより「読み上げ」をサポートする
方が汎用性が高いと思いますけど。
# 読めない実身名(ロゴとか)だと困るけどね。
--- 林(takanori@ohsaki.meidensha.co.jp)