ばいなり・しょっく？

  ショックが大きかったのか、意見が出ずに、凍ってますね。
こんなんじゃいけない。熱く語るんだぁ。


＞データのアーカイブはどんなふうにやるのがいいのでしょうね。
＞CNFバイナリ化も含めるということですので、
＞単に、tarしただけのものではなさそうですね。

＞さらに、簡単な圧縮をかけるかどうかも問題。
＞圧縮をかけないのなら、
＞どうせLZHのまま管理することになって、
＞現LZH直視と大して変わらない…って言われちゃうかも。

  ＺＩＰやＬＨＡといった２次圧縮を期待するなら、むしろ、複雑な圧縮をし
ない方が、結果として、サイズが小さくなると思います。ディスク上でのデー
タサイズについては、ＭＯとか大容量媒体の普及により、あまり苦痛でないと
思います。読みこみにかかる時間と展開にかかる時間のバランスもたいせつで
しょうが、今日のＨＤはかなり速いですから。
  ディスクのクラスタサイズが大きくなってくると、小さなファイルがたくさ
んある形は不便だと思います。

＞じつは、わたしは、セルファイルなどをまとめる場合でも、
＞CNFは別ファイルでテキストファイルのままにしておくことを考えていました。
＞理由は、３点。
＞(1)バイナリ化すると、周辺ツールがないと何もできなくなってしまう。
＞(2)気軽に修正ができない。
＞(3)差分データはどうするの？

  バイナリ化と、セルファイルの統合化は切り離して考えても良さそうですね。
現在のような複数のＣＮＦを使い分ける形をとるには、別けた方が便利そう。
でも、そうなると、今のような「データごとにひとつのフォルダを作る」とい
う形を取る必要がありますね。このあたりは、解説ドキュメントをどうやって
添付するかという問題とも関係します。

  データを改訂したり追加を作りやすい形が良いのか、逆に、簡単に改変でき
ない方が良いのか。このあたりも論議が必要でしょうね。

  私としては、今のｆｋｉｓｓのような形の物を開発用ツールとして残し、こ
れをもとに一体化したバイナリを生成する方式を支持します。配布形態は、原
則としてバイナリとしておけば、ユーザ側で勝手に改変できません。著作権表
示を変えられる危険も少なくなります。
  データ作成環境は、現行の物を利用できますし、簡単な物であれば、現在の
ｆｋｉｓｓを使ってデバッグできるでしょうし。
  あまり、変わりばえしないでしょうが、バイナリ化したｃｎｆと、セルとパ
レットを単純にシーケンシャルに結合した物という組み合わせはどうでしょう
か。セルの追加は単純にアペンドできますし、管理上の問題はクリアしますし、
ディスクスペースの点でも少し改善します。


＞現在のGSランクのような記述では、
＞データのスペックをあらわすのは難しいように思います。
＞この作品は、この環境（ローダー）で遊べるのか？
＞ということを判断する、新しい方法が必要になりますね。

  このへんは、しばらく前から私が言っていた、ガイドラインの作り方だと思
うのです。「この機能がないと遊べない」「この機能があった方が楽しめる」
というような、データ側の要求の程度の違いがありますし、ローダ側も、「あ
る機能は無視する」といったインプリメントを考える必要があると思います。


＞yavさんが言われた、サーバー・クライアント方式での問題
＞に関しては、よくわかりません。
＞もし、宜しければ、お時間のあるときで結構ですから、
＞解説していだだけると嬉しいです  ＞ yavさん

  う〜ん、ボクは、個人的にはあまり意義を感じないのですが、何か面白い使
い方か何かあるのかしら。ＪＡＶＡでＫＩＳＳってのは、クライアント側でや
っている訳ですし。サーバ側でやっているのって言うと、Ken Stone さんのホ
ームページにあるようなのかしら。


	さあ、もっといろんな人が意見を出すべきだと思います。

					ＭＡＲＳ