[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