[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1391] Re: BTRON2 はオブジェクト指向 OS か?




隆一です。


From: Hidekazu SHIOZAWA / 塩澤秀和 <shiozawa@myo.inst.keio.ac.jp>
Subject: [b-free: 1388] Re: BTRON2 はオブジェクト指向 OS  か?
Date: Fri, 17 Apr 1998 14:38:21 +0900

> 塩澤です。
> 
> From: Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>
> Subject: [b-free: 1384] Re: BTRON2 はオブジェクト指向 OS  か?
> Date: Fri, 17 Apr 1998 14:04:42 +0900 (JST)
> 
> > Java アプレットだと、適当にサーバを立てて、そのサーバを PDA に指定する
> > おくことになると思います。自分の持っていない Java アプレットが必要になっ
> > たら、自動的にサーバからダウンロードします。
> 
> 近いダウンロード元サイトを
> 教えてくれるだけのサーバをかます
> 必要がありますね。

えぇ、サーバが必要になるのは、組み込み機器の場合だと面倒なことを引き起
こすことになると思います。

今のところ組み込み機器で Java を使おうというところでは、Java アプレッ
トをダウンロードすることを考えていないところも多いようです。

http://www.hotwired.co.jp/news/news/530.html の記事では、Java のクロス
プラットフォーム機能はプリンタのような組み込み機器では意味がないという
話が載っています。


> > 問題は Java アプレットをダウンロードするマシンの数が増えた場合です。
> > ビデオレコードとか、テレビ、炊飯器、、、組み込み機器の数は膨大です。
> > 極端な話になると白熱電球にも OS が入るようになるかもしれません。
> > そういうマシンの数が 100 個とか 500 個になった場合、いちいちサーバがど
> > れかを指定するのは大変なことになると思います。また、サーバマシンをリプ
> > レースしてアドレスが変更になった場合、すべての組み込み機器の設定を変更
> > する必要があります。
> 
> それこそ、DHCPみたいになっていて、
> 機器がブロードキャストして、
> ネームサーバを「発見」するのでは。
> 

DHCP だとブロードキャストが届く範囲でクライアントにアドレスを割り付け
ます。とどかないところにも中継するリレーサーバもありますけど、基本的に
はブロードキャストが届かないところでは使えません。
NIS などでも、サーバを発見するためにブロードキャストを使っていますね。

でも、ブロードキャストが届かない場合もありますよね? 特に、組み込み機
器の場合だと、通信が電灯線を通じて行うとか、赤外線で行うとか複数の媒体
を使うと思われるので、ブロードキャストを使うというのは難しいのでは?


> そのサーバは、ダウンロードサーバを教えてくれる。
> 
> そのダウンロードサーバはプロキシーサーバになっていて、
> さらに上流のダウンロードサーバから持ってくる...

いやだから、サーバの構成が変更することを考えたら、サーバの管理が繁雑に
なりませんか? 一旦サーバの構成を決めてしまえば、ずっと変更しないとい
うことかもしれませんが、サーバが故障してしまうこともあるだろうし。。。

サーバが複数に分散しているような環境の維持って、管理が大変になると思い
ます(DNS がいい例です。あれもサーバの入れ換えはそれなりに手間がかかり
ます)。


できたら、サーバみたいな集中管理機構は無しにしたいですね。
組み込み機器やリモコンなどが協調して環境を形づくるような。
「環境」は、さまざまな機器の集合で成り立っていて、どれか一つが落ちて
も「環境」には影響を与えないようになっており、自発的に互いの能力を補う
ようなこともできるとかしてくれるといいですね。

たとえば、

・エアコンを使うときの癖(何度以上になると、エアコンを入れるようにして
  いるとか)を「環境」が覚えており、エアコンを買い換えてもその癖をおぼ
  えていてくれる。エアコンの固有の性能差はエアコン自身の情報で補正する。 

・ビデオレコーダを買い換えても番組予約の内容を自動的に引き継いでくれる。
  (「環境」が番組予約の内容をおぼえていてくれる)

・留守電機能のついた電話機の内部記憶の空き容量がなくなってきたら、
  自動的に「環境」中のどれかの機械の記憶装置に記憶してくれる。もちろん、
  留守電の内容を聞くときには、そんなことは意識しない。

・ビデオで予約録画していて、テープがなくなってしまったら、「環境」中の
  どこかの記憶装置に続けて録画してくれる。どんどん録画すると段々空き容
  量が減っていったりして。。。 

とか。

# もちろん、具体的にどうすればいいのかは考えていません :-P


> > 問題は、どうやって対象となる機械を指定するかです。たとえば、手元のラン
> > プの光量を絞りたい場合、どうやって「手元のランプ」を指定すればいいんで
> > しょうか?
> 
> ランプに無線が積んであるか、バーコードが貼ってあります。
> バーコードには出荷時にMACアドレスが印刷してあり、
> リモコンについているカメラをそちらに向かせると、
> バーコードを読み取ります。
> 
> カーソルに相当する概念があって、
> 指定を受けた電球はユーザに分かるように反応します。
> ユーザは、それを確認して、光量を調整します。
> 
> ... というのは。

これって制御したい機器が見える範囲でないと操作できないということですよ
ね。
makotan さんのメイルにあったように、家の外から機械を操作する、なんてい
うことはできないです。そもそも、見える範囲にあったら、直接操作する方が
早いことも多いでしょうし。。。

# ランプが自発的に情報を提供することは大事だと思います。あとは、ランプ
# の物理的な位置をネットワーク上に通知するようにすれば、物理的な位置を
# 指定することで、操作できますから。


> > ひとつの方法は、自分のいる周りの状態をディスプレイで表示することです。
> > 手元のランプだったら、手元のランプをポインティングデバイスか何かで指定
> > し、光量を絞れという指示を入力します(そう、昔 MS が出した Bob のように) 。
> 
> ヘッドマウントディスプレイをかぶって、指さすというのは。

これも、組み込み機器の物理的な位置を何らかの方法で知る必要があるんでは
ないでしょうか?

# でも、いちいちヘッドマウントディスプレイをかぶるのも大変ですね :-)
# 会社では、会社用のヘッドマウントディスプレイをかぶり、家に帰ると別の
# ヘッドマウントディスプレイをかぶる。。。


> > 具体的な動きとしては、多分機械をネットワークにつないだ途端に、サーバか
> > 聞いてくるようなことになると思います(うーん、めんどくさい)。
> 
> ふつうの部屋には電球は1個ぐらいしかないでしょうから、
> 位置までは要らないかもしれませんよ。
> 「(the)電球、消えろ!」と叫ぶとか。

テレビやラジオを使っていると、大変そうですね :-)
「消えろ!」というセリフで、音の届く範囲の機器が一斉にダウンしてしま
うとかになりそうです。

自分の部屋の電球を消すつもりで叫んだら、隣の部屋の電球が消えたりとか。。。


> 基本的には、電球にまで複雑なプロセッサが
> 載るかどうかは、疑問です。

まぁ、電球は例であって、別にビデオでもテレビでもいいんですが。。。

しかし、この前の JavaONE では指輪にプロセッサと通信機能が入ったみたい
ですから、電球くらいだったら入るでしょう。
電源の心配はないし、通信も電灯線を使えばできますから。

電球にプロセッサが入るとどこがいいかというと、電球のスペックを電球自身
が知っているようにできることです。制御機器を別にしてしまうと、電球のス
ペックを何らかの方法で知る必要がでてしまいます(えっ、電球にバーコード
を張りつけて買ったときに登録すればいいですか? それって、面倒じゃない
ですか)。


> 電球に対する要求を、他のコンピュータが
> 代理(Proxy)になって処理すれば良いわけですから。
> かなりも「もの」はそうなると思います。
> 最低限必要なのは、センサーと通信装置(あるいは電線)だけです。

こうやってしまうと、電球を制御するためにどこかに制御機器を追加すること
になります。家庭でどうやるかを考えると、電球のスイッチボードにプロセッ
サが入ることになると思います(電球を制御したいことを考えると、少なくと
もスイッチには手を入れる必要があります)。

でも、交換の手間はスイッチボードの方が大きいわけで、もともと交換するよ
うに作ってある電球にプロセッサが入ったほうが手間がないような気もします。
(故障したら、ノンインテリジェントタイプの電球に換えることもできるし)


> > で、こーゆーことを解決するには、どうすればいいのかと考えると、多分、オ
> > ブジェクト指向のような基本的に一対一の通信をベースにした技術では難しい
> > ような気がするわけです。
> 
> たしかに、そうではあるんですが、
> オブジェクトをまとめたオブジェクトを作っても
> 解決しないのでしょうか。
> 「環境」というオブジェクトを作るとか。

実はこの解決方法は「TRON プロジェクト '90 - '91」に載っていました。
やっぱり、何らかの理由で「使うべきでない」という結論になっていたと思い
ます。

「環境」オブジェクトを作ってしまうと、そのオブジェクトを管理するマシン
の負荷が大変になりませんか? そのマシンを発見するために、どうするかと
いう問題も出てきそうです(再帰的ですね)。

それに、落ちてはいけないマシンができてしまうような。。。
(「環境」オブジェクトを支えるために、複数サーバが動くようになったりして)



p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
b----------------------------------------------------------------------d