こんにちは、川合です。
今日は、OSASKのAPIの仮想化についてあれこれ書きたいと思います。
きっかけは昨日の夜、nikqさんとIRCでネットワークサポートAPIにつ
いて話したことです。
nikqさんは、たとえば、GetHostByAdrr()みたいなファンクションを
ぐいぐい00仕様に追加したらどうかと提案しました。これは、IPアドレ
スをシステムに渡して、結果としてホスト名を受け取るようなファンク
ションです。
僕はこの提案に強い難色を示しました。・・・その理由は単純明快で
APIの仮想化の観点によるものです。この点について今からいろいろ書
きます。
結論から言うと、一般アプリケーションは、自分自身や通信先のIPア
ドレスを知るべきではない、というのが僕の考えです。一般アプリケー
ションがIPアドレスを知るのは、ファイルの格納されているクラスタ番
号を知ることや、自分が走っている物理アドレスを知ることくらいに、
汚らしくて危険なことです。
ましてや、アプリがダイレクトにIPアドレスを指定して、そのIPアド
レスに関する情報を獲得したり、接続できてしまうというのは大いに問
題です。
・・・しかし実際問題として、これを禁じてしまうとアプリはネット
ワークを使えないじゃないかという反論はあります。これについては、
僕なりの解決案を提案します。
---
OSASKにおけるAPIの仮想化は「他のOSにくらべれば」徹底しており、
ファイル名を知ることなくファイルにアクセスしたり、実際のキーバイ
ンドがどうなっているかを知ることなくキー処理ができます。・・・な
んでこんな仕様になっているのかといえば、たとえば以下のような説明
ができます。
ファイル名を知らなくて済むということは、ファイル名を記述する方
法がどんなに拡張されてもいっこうに構わないということです。ファイ
ル名にどんなキャラクターコードを使ってもいいし、ファイル名の長さ
が当初の予定よりも長くなってもいいし、デフォルトパスがどうなって
いるかなんてことにも頭を悩ませる必要がありません。
これによりディレクトリ構成は柔軟になり、APIのファイルシステム
からの独立性が高まり、たとえば同名のファイル名を許すようなファイ
ルシステムでもアプリの変更なしにサポートできるようになります。ア
プリの動作を止めることなくファイルを別のディレクトリへ移動させた
り、ファイル名を変更することだってできます。
キー入力の汎用シグナル化についても、利点がたくさんあります。こ
れは他でも書いた気がするのでここでは省略します。
僕はこれと同様に、IPアドレスはアプリから完全に隠されるべきだと
思います。またアプリがIPアドレスを指定して送信相手を指定できると
しても、それは容易にオーバーライドできるようになっているべきです
（つまり、アプリは111.222.111.222と通信しているつもりなのに、実
は123.123.123.123と通信しているとか）。仮想化するのはIPだけでは
なくドメイン名も同じです。
まあ本音を言えば、そもそもアプリがIPアドレスを指定できるという
仕様は、仮想化の観点では言語道断な気がしますが。それなりのセレク
タをシステムが提供し、その設定値はアプリからは全く見えないという
のが、仮想化の観点からは標準的な実装です。
すぐに分かることですが、仮想化されたネットワークAPIの元では、
ウイルスや悪意のあるワームの繁殖や攻撃は極めて困難です。たとえば
何からの方法でシステムから個人情報を盗めたとしても（そもそもそれ
が無理な気はしますが）、それを特定の誰かに送ることができません（
IPやドメイン名を指定して送信できないから）。繁殖しようにも、どこ
へ送るかはセレクタでユーザに選んでもらわなければならず、繁殖活動
が丸見えです。攻撃も、たとえば指定した時刻に指定したサーバを攻撃
するなんてことは、実際の時刻を取得することすらままならない仮想化
APIの元では、もう絶望的です（もちろん攻撃対象の指定もできません
が）。
また仮想化しておけば、IPv6へ移行したり、そのほかのより高度な拡
張があったとしても、アプリケーションはそのまま使えます。
---
仮想化した中でのメールソフトを考えてみました。まず、メールソフ
トはメールアドレスを知ることはできないという原則に立つと、適当な
ニックネームをつけてそれを選ばせるか（もちろん、ニックネーム＝メ
ールアドレスであってもいいのですが）、シェル提供のファイル選択ダ
イアログのような物が出てそれで送信先を選択するようなスタイルにな
るでしょう。メールソフトを複数使っていても、メールアドレス選択ダ
イアログは共通に使えることになります（逆に言えば、それがぼろいと
みんなぼろくなりますが）。
メールのヘッダもメールソフトが直接生成することはできず、printf
()のように、エスケープキャラクタ部分に自分のFromが入ったりするの
でしょう。受信したメールもシステムからの検閲がかかり、メールアド
レスに関する部分は削られたり編集されたりするでしょう。
自分でいうのもなんですが、これはなかなかにきつい世界です。こん
なのいやだーという意見もなんとなくうなずけます（まあでも、僕なら
この制限下でもいろいろな事ができそうな気もしますが）。
これを回避する簡単な方法は、メールソフトは一般アプリではない、
ということにするしかないでしょう。システムの一部（シェルの下請け
）だということになれば、まず間違いなく一般的な傾向として、ソース
の全面公開が求められます。そしてみんなでソースをチェックして、信
用できると判断されて、使われるようになります（判断が出る前に使っ
てもいいですが）。・・・一般アプリは、悪さできる範囲が限られてい
るので、クローズドソースでも十分に歓迎されます。システムでクロー
ズドソースの場合、他の人は認めるかもしれませんが、僕は絶対に推奨
を出すつもりはありません。
---
さてGetHostByAddr()のようなファンクションはどうやって扱うべき
かという最初の問題に戻りますが、これはシステムレベルで隠蔽するし
かないだろう、というのが僕の見解です。
つまりGetHostByAddr()みたいなファンクションを使うプログラムを
書きたいというなら、それはシステムアプリとして書くか、もしくは、
こういうファンクションを呼び出す部分をシステムDLL化して、ソース
を公開するしかないというわけです（その場合、ソースをチェックする
人たちは、アプリ側に実IPや実ドメイン名がもれる心配がないかどうか
チェックします）。
こんな仮想化にこだわったら互換性がなくなって世にあるソフトが移
植できないじゃないかー、という突っ込みはもっともです。しかし、そ
もそも移植性なんて最初から捨てているので、そんなこと指摘されても
対応に困ります。
僕としては、移植性を維持するために仮想化を捨てるくらいなら、OS
ASKそのものを捨ててLinuxにでも移行する方がいいと思っています。・
・・ただ現在は実用第一主義という方針なので、移植性をあっさり捨て
るのは大いにためらわれます。ですから、システム用APIにこれらの互
換性の高いAPIを配して、これを「えせメーラ」などとしてしばらくは
我慢する、というのがベストなのではないかとも思います。
---
長くなりましたが、ご意見やご感想があれば、是非レスをつけてくだ
さい。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/