SHIORIの共用化案

SHIORIの共用化とは

• MATERIAとは違い、偽林檎やninixでは栞に当たるものが全ゴーストで共用。だから栞がプラグイン扱い。
• 現実問題として、栞をゴーストごとに持つのはダウンロード時間、ディスクスペース的に無駄。
• Windows上でも同じ事が出来てなにが悪い？
• 案外多くの人がこの意見を持っているようなので、やれるかどうか詰めてみよう。
• 随時突っ込み・書き換え大歓迎。コメント程度でも嬉しい。

メリット

• ゴースト作者はゴースト配布の際、栞を同梱しなくてもよい。アーカイブを小さく出来る。
• ユーザは栞の分のディスクスペースを節約出来る。多くのゴーストを入れるほどメリットが出る。
• 栞のバグフィックス時、ゴーストの数だけ同じDLLをダウンロードしなくてすむ。
• 既にSSP BUGTRAQ提案のPLUGIN/2.0と共通点が多い。(リンク)
• ゴースト側でも使える栞のバージョンをdescript.txt等に明記するべき。上限と下限。
  • ゴーストマスタが上限と下限を管理するのは無理があると思う。
    • 結局のところ、「対応バージョン必須」が一番問題が少ないだろう。それでも、バージョンアップが余程激しい栞で無い限り、省スペースのメリットは損なわれないはず。
• ゴースト作者のdescript.txtへの記述の苦労は、ツールで解決できるだろう。
• 記述がやりやすいよう、栞共通のバージョン命名規則があるといいかもしれない。
• 共用栞dllを呼び出す小さな子栞dllを使えば、いまのMATERIA規格下でも可能かもしれない。
• 今の栞との共存も十分可能。そのゴーストだけの独自栞を持ってもいい。

課題

• 同じ栞でもバージョンの違いで使える機能に差がある。共用化の為には栞にバージョンごとでID(GUID)を振るべき。
  • IDはdllのMD5値でいいんじゃないの？
• ゴーストのdescript.txtに記載されているバージョン範囲と存在するバージョンが違った場合、descript.txtの自動書換等を視野に入れる必要あり。
• バージョン管理が一番の肝なので、既成の管理方法を借用するか、熟考した上で管理方法を発明する必要がある。
  • NetBSDとかDebianのパッケージ管理システムが参考にならんかなあ。教えて高志お兄ちゃーん
    • shared library じゃなくてパッケージなの?
    • NetBSD のパッケージシステムは FreeBSD のパッケージシステムをぱくったもので、けっこう破綻してます。つかバージョン違いの共存は考えてませんでした。
    • FreeBSD のパッケージシステム、日本語版。
• 栞DLLが複数インスタンスに対応する必要があるかもしれない。
• マルチプロセス化すれば複数インスタンスは要らないが、本体の機構との兼ね合いが考えられる。
• 栞作者のサイトにユーザからのダウンロードが集中する可能性がある。
• 栞自動ダウンロード機構がないと、「初めての伺か」の敵になる。以下、機構の一例
  • descript.txtには使用する栞、バージョンを明記する
  • descript.txt記載のURL、ネットワーク更新URLに、栞のアーカイブを置いておく
  • 上のURLから、本体が必要に応じて栞をダウンロードする。
  • 栞のアーカイブが先のURLに見つからなければ、栞の名前情報を頼りに本体が栞作者のサイトからダウンロードする。
  • descript.txtに、ゴーストマスタが開発に使用した際の栞バージョンを本体が自動追記すると楽かも。updates2.dauの要領。
  • この方法は、バージョン命名規則を真面目に考えないとうまく機能しないかもしれない。
• 「初めての伺か」に関連して、この方法ではクリーンな環境を一から作る際の手間が多い。本体作者、栞作者と合意の上、スターターキットを作るといいのか？
• 本体と本体作者に仕事を押し付けすぎかもしれない。分業できる方法は無いか。
  • 一通りの栞アーカイブと、ゴースト配布時に今まで通り同梱してもらってローカル無いバージョンならローカルのアーカイブ保存という形とか。

---

突っ込み、コメント

• 複数インスタンスに対応しているかどうかのフラグを栞が持っていれば良い？対応していなければ(多少重くなっても)マルチプロセスで。 -- 名無し~3.EXE 2003-04-23 (水) 22:29:52
• 話具体的になってるのかな？栞がすべてのゴーストの動作を保証する必要とか出て来るわけで、逆に開発が硬直化するとか有りそう・・・。といいつつも、大幅な改定が有るかというとなさげですが。 -- 名無し~3.EXE 2003-04-25 (金) 18:31:35
• 全て保証……は、重過ぎるのう。無条件にアップグレードしていいもんでもないよなあ。意図せず動かなくなる可能性はいくらでもあるし。無条件に差し替えるには、「ゴースト側の変更なしでいいように」更新したものでないと。それでもやっぱり動かなくなる可能性もあるわけで -- 2003-04-25 (金) 23:24:04
• 保証、といっても全ゴーストをチェックするわけにもいかないわけで……迷う。実現方法を少しおいといて、動機に戻ってみようか。 -- 2003-04-25 (金) 23:26:23
• メリットは端的に、ゴーストアーカイブを小さくできること、重複DLLが１つになってディスクの節約になること。デメリットはゴースト作者の手間が少し増えることと、結構な作業量によりバグ混入の余地も増大すること（本体のバグ以外に設定系の問題、環境作成の難易度向上が怖い）、複数バージョンを同一視する方向性だとオリジナル環境たるWindowsですら互換性の問題が発生するところ。……何か「こんな面白いことができる」というのが欲しいね。技術的面白さでもいいんだけど、プログラマの自己満足だけではいまいち。ディスク占有量に大きな不満を持っているユーザは多くないと思われる。一方でナローバンドなユーザはまだまだいるだろうが……ADSL等の普及マップは見てみたいところ。 -- 2003-04-26 (土) 01:44:08
• まあ非Win互換系では動作が少しくらいおかしくても大目に見る、ってのはあるからねえ…　完全な動作はきついかも -- 名無し~3.EXE 2003-04-26 (土) 02:24:26
• この手の話が、しょーも無いGPL回避目的だったと仮定してだが・・・、perlなりruby也のランタイムを落として共有させるとかの用途ならば有効かもしれない。しかし、そのような栞を使うゴーストってのが希なんだけどね;-) -- Aoe 2003-04-26 (土) 02:48:43
• 俺としては、GPLはどっちゃかというとオマケ。回避できるとそれはそれで嬉しいが。華和梨6だったかでセキュリティホールが見つかったり、今回の里々のフィックスとか、ああいう「緊急かつ漏れなく差し替えなければならない」ケースにうまく対応できないか、というのが自分の動機。 -- 2003-04-26 (土) 09:10:14
• もちっと絞る。「使ってはならないバージョン」の、ローコストな駆逐。しかし、ここまで限定すると使える局面が減るなあ…… -- 2003-04-26 (土) 09:34:31
• 栞が全ゴーストの動作を保証する必要はないのでは。基本的にはバージョンの上限下限ではなく動作確認済みのバージョンを決め打ちってするならば。 -- 名無し~3.EXE 2003-04-29 (火) 11:42:55
• 非Win互換系にとっては形態が近くなるので喜ばしいのかも。 -- 名無し~3.EXE 2003-04-29 (火) 11:47:20
• ゴーストが増えると、動作する複数の（バージョン違いの）同じ栞をインスコする必要もでてくることになると、容量的メリットはなくなるか・・・ -- 名無し~3.EXE 2003-04-29 (火) 18:11:17
• ↑さに非ず。ゴーストの栞は大抵、いずれはVer.Upされる傾向あり。ゴーストエクスプローラのような乗りで、「この栞のこのバージョンは誰も使っていない」と判断することは出来るから、死蔵栞の危険は回避可能。 -- 2003-04-30 (水) 10:10:42
• 「ゴースト管理」について考えてみるのもアリだろうか。栞のマネージメントはghostのマネージメントと切り離せないわけで（切り離したいのがこの案か？）。現在、ゴースト数が増えると右クリックメニューがスクロールし、利便性が劇的に減少してる。それで結局複数の本体をインストールし、そうなってると共用化のメリットも減ってしまうわけですが。 -- 2003-04-30 (水) 13:05:07
• SHIORI っつーレイヤは重要だと思ったりも。 shell の SHIORI 的なアプローチもあったわけだし(なつきさんね -- 2003-05-01 (木) 04:15:50