1023kis00166ELME 1995/09/25 22:57:02 前へ 後へ 上へ

KISS THE NEXT GENERATION!


最近、ちょっと次世代KISSに関しての書き込みが鎮静してきたみたいなので、
ちょっと書いてみたいと思います。



以前も書いたのですが、CEL/KCFを1個のファイルに連結したフォーマットを
採用して欲しいのです。

これには、幾つかの理由があります。


1.ディスク容量の節約

ファイル数が多いことによるクラスタの無駄を無くしたいという訳です。
細かいパーツが多いKISSだと、おおよそ2倍くらいにふくれあがるみたいです。
CELを圧縮するよりは、効果的だと思います。



2.ファイル数の増加による管理の限界

最近、合作データを制作発表する機会も出てきました。
出始めの頃はそれこそ大した容量を盛り込む事もなかったのですが、
データ制作者が熟練すればするほど、大量のCELを必要とするKISSを
つくる事ができます。

先日、合作データの管理を行っていたところ
圧縮ファイルに対してDOCのみを閲覧しようとした所、
全てのファイルをアクセスする事が出来ない事がわかりました。
原因は、LZH内視ビューアーが512個以上のファイルを読めない事でした。

将来的に、CELファイルはどんどん必要になってくると思います。
1024個以上のCELを必要とするデータもでてくるのではないのでしょうか?
そうなると、いくつかのファイルセレクター上で管理できなくなってしまいます。

これ回避するために、オリジナルアーカイブの中は
CNF と データファイルの2個だけで済むフォーマットにして欲しいのです。



3.合作データや差分データを柔軟にサポート

私が、ファイルを一個に連結する話を持ち出した時に、言われたのが
「差分データへのサポート」問題でした。

そこで、連結データのファイル名をCNFに記述する際に
マルチパレットみたく複数の連結データファイルの記述を行う事で、
合作データや差分データをサポートし、さらに合作時などで作者間で
ファイル名が重なっても、データファイルの指定さえしっかりしていれば
同居出来るようにすれば、ますます制作編集が容易になると思います。



という事ですが、いかがなもんでしょうか?
余談ですが、ファイル数が少ない方がアーカイバーの圧縮率はいいと思います。

できれば、既存のLZH内拡張子自動判別実行プログラムでの実行が
容易なファイル構成だといいのですが、そうもいかないっすね。



 ELME

No Java Java

前へ 後へ 上へ