[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 891] Re: サポート
隆一です。
From: Kazuhiko Iwama <with@st.rim.or.jp>
Subject: [b-free: 887] Re: サポート
Date: Thu, 20 Nov 1997 18:03:11 +0900
> ■ [b-free: 881] Re: サポート
> □ Ryuichi Naitoh<naitoh_r@soft.hitachi.co.jp> さんへのお返事
>
> 岩間です。
>
> ■ Ryuichi Naitoh さんのメールからの引用です
> □あと、モジュールにバグがあったことを考えると、元のモジュールを残してお
> □かないといけないですね。立ち上がらなかったりした場合は、元のモジュール
> □を使えるようにしないと、OS を再インストールするはめになっちゃいますか
> □ら(これがいちばん難しい?)。
>
> 実際には入れ替えをする必要はないわけですよね。
>
> だったら、バージョン情報がわかるように、別のファイルとして
> ファイルをコピーして、ローダーがそれらを選択しながらロードす
> るのでもいいですよね。これなら、更新前のモジュール一覧(含む
> バージョン情報)を保持していればよいので、トラブル時の復旧も
> 難しくないと思います。
考えてみると、こういうものこそバージョンつきのファイルシステムが役に立
ちそうです。
ただし、あまり古いアプリケーションを残しておくのもなんですから、適当な
タイミングで自動的にパージする機構があれば便利ですね。
アプリケーションマネージャとかがあって、それでアプリケーションの更新や
パージを集中管理するようにするとか。しかも、ネットワークでアプリケーショ
ンマネージャ同士が通信しあって、一台にアプリケーションを入れると自動的
に徐々に広がっていくとか。しかもしかも、使用頻度を計算してあまり使われ
ないアプリケーションは(ネットワーク的に)遠いサーバへ保存して、各マシン
のディスクからは消すようにしてしまうとか。もちろん、必要な時にはサーバ
から呼び出して使います。
で、最後にはディスクの中にはゲームばかりが残って、ビジネスアプリはいつ
の間にか消えてしまうわけですね :-P
>
> でも、モジュールの更新って、どのようにしたらユーザーにとっ
> てわかりやすくなるんでしょうかねぇ。ぼくは、Windows のような
> 方法は、アプリケーションが同時に使えるので好きでないのですが、
> そう思う人って少ないのかなぁ。
>
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d