AirCraft の基本コンセプトは、あらゆる情報をつないで整理することです。情報をつなぐとは、人と人をつなぐことです。ただ箱へ情報をつめこむだけのソフトウェアではありません。 手動によるアクセスで取得した情報と、オートパイロットによるアクセスで取得した情報を統合しているのも、すべての情報は有機的に結び付けて整理しなくてはならないというコンセプトから来ています。情報の分断化を避けることを第一に考えています。 AirCraft による整理とは、単にログファイルを切り分けて保存するだけではなく、ユーザが求めている情報をあらかじめふるいにかけて抽出することです。抽出された情報は、オリジナルの情報群へとリンクしています。 ふるいにかけられた情報を糸口に、自分の興味のある流れにそってコミュニケーション空間を自在に行き来できる環境、それが AirCraft です。 |
最近では、通信人口の増大と、テレホーダイ等の電話料金の割り引き、ハードウェアの性能向上などにより、多くの情報を取得できるようになりました。逆に、すべての情報を読むだけの時間がなく、重要なメッセージを見逃してしまうなどの弊害がないわけではありませんでした。それを解決するひとつの答えとして実現されたのが、トピックス機能です。
トピックスは、ハイパーリンクログデータベースと連携して動作する、AirCraft 独自の機能です。新規に取得された情報に対して、インデックス付けと全文検索を同時に行うのが特長となっています。全文検索は、内部的には有限オートマトンを利用した正規表現による高速パターンマッチを採用しています。
トピックスは、ハイパーリンクログデータベースと連携して動作しますが、それが実現できたのは、マルチスレッド技術を採用したからです。ハイパーリンクログデータベースやトピックスがマルチスレッドで動作しているため、常にログデータベース全体を最新の状態に保つことができるので、トピックスも常に更新された状態となるからです。
たとえば、各会議室のログをブラウザで開くタイミングでログデータベースを更新するようなやり方だと、その会議室を開くまでトピックスも更新されないことになります。これでは、「あらかじめ自分にとって重要な情報を教えてくれる」というトピックスの機能は半減してしまいます。
また、ログデータベースがハイパーリンクを高速にリゾルブできるので実現できた機能とも言えます。
このように、トピックスは、ハイパーリンク対応のログデータベースやマルチスレッドなど、最新の技術と密接に関連している、AirCraft にしかない機能です。
32bit の Windows 環境は、マルチスレッドモデルで動作しています。マルチスレッドは、いわゆるマルチタスク(マルチプロセス)以上のものです。マルチタスクの概念も包含しています。
マルチスレッドというのは、1つのプログラムの内部で複数の処理が平行して動作することを言います。たとえば AirCraft で言えば、巡回を行いながら、ブラウザでログを見ることなどです。それぞれを平行して実行することができます。16bit の Windows でも似たようなことはできましたが、それはプログラムをおおざっぱに細切れ実行していたに過ぎません。あまり複雑な処理を平行して動作させることはできませんでした。できたとしても、せいぜい2つの処理を平行動作にみせかける程度でした。
1つのプロセスに1つしかスレッドが存在せず、そのようなプロセスが複数動作している状態は、マルチプロセスと同様ということになります。そのため、マルチスレッドモデルは、マルチプロセスモデルの上位の概念ということになります。
AirCraft では、常時、10本程度のスレッドが動作しています。ログデータベース、アドレス帳の自動更新、通信処理、検索、予約状況タブ、PADの監視、アクティブブラウザの更新など、多数の処理が分散されています。
もっとも、マルチスレッドといっても、CPU は1個か2個しかないので、実際には、オペレーティングシステムが平行動作に見えるように、スレッドを細切れにして、高速に切り替えながら実行しているに過ぎません。しかし、マルチプロセッサのシステムでは、別々の CPU にスレッドを割り振れるため、より並列動作に近いものとなっています。
AirCraft を作りたいと思ったのは、このハイパーリンク構造を持ったログデータベースに興味があったからと言って過言でありません。
ハイパーリンクログデータベースは、AirCraft の全体のサービスの基本を支える部分です。マルチスレッドに対応した処理のため、バックグラウンドで自動的にデータベースが更新されるのが特長です。
AirCraft のハイパーリンクログデータベースには以下のような機能があります。
ネットワーク(LAN)対応とするために、ファイルのロック機能とともに、ユーザごとにフラグの管理を別に持っています。通常は、ログファイルのインデックス付けと、未読などの情報は同じところで管理されていますが、AirCraft ではこの2つを分離することで、同じログファイルに対して、複数の見方ができるようになっています。つまり、同じログファイルを LAN 上で共有していても、ユーザごとに未読状態やツリーの状態、チェック状態を分けることができます。
その他、オートパイロット処理やアドレス帳データベースのスレッドと同期を取りながら、情報のやりとりをする機能などがあります。
ハイパーリンクログデータベースは、NIFTY MANAGER が NIFTY URL に対応する以前から開発されていました。ちょうど、AirCraft がリリースされた直後に、NIFTY MANAGER が NIFTY URL という表記を実装したので、それにあわせた形の URL を使うようになったものです(それ以前は、FAIRTERM MES 12 #45 のような表記を認識してハイパーリンクしていました)。
会議室のハイパーリンクは、WWW で使われるものと異なり、動的に参照されるものである点が興味深いところです。つまり、日々刻々と変化する別発言へのリンクを、会議室でやりとりしているわけです。これは、あまり大きく取り上げられることはありませんが、電子メールや WWW では見かけられない、新しい形態のコミュニケーションです。リンクの生々流転を肌で感じることができること。僕がやりたかったのは、これなのです。実体の引用に頼っている電子メールは、旧世代のメディア構造です。
ナビゲータやオートパイロットのモジュールは、階層で管理されると同時にマルチスレッドで動作していますが、だいたいは上のような構成になっています。
AirCraft においては、ナビゲータとオートパイロットの違いは、実行のトリガーがユーザインタフェースにあるか、オートパイロットのディスパッチャにあるかの違いでしかありません。表向きは全く異なるように見える機能も、内部では統一されたインタフェースで管理されています。全文検索 のような新機能にいち早く対応できたのも、内部の構成が統一されているため、機能の追加が楽にできるからです。
AirCraft は、NIFTY の全文検索サービスに対応しています。
全文検索とは、ホストにある特定のフォーラムの全発言の本文を対象に、キーワードの検索を行う機能です。これまでも、タイトルのみの検索や発信者名による検索はありましたが、98年の夏に、本文の任意のキーワードを検索できるよう NIFTY のホストがバージョンアップしました。これに対応したものです。題名とは全く異なった本文の中からも、興味のあるキーワードを探し出してくれるので、とても強力な機能です。必要な発言だけダウンロードできるからです。
全文検索サービスへの対応は、ナビゲータの機能の一部として実装されています。オフライン状態で検索条件を入力すると([サービス(S)]-[フォーラム全文検索へ移動(K)])、オンラインの場合はその場で「全文検索サービスへ移動を行い、指定された条件で検索をし、結果を出力する」スレッドを生成します。
結果はメインスレッドにあるウィンドウで見ますが、検索は別なスレッドで行われ、随時、ヒットしたものをメインスレッドへ同期して転送しています。さらに、メインスレッドで、本文を読みたい指示があった場合は、新たに本文の取得を行うスレッドが生成され、その結果も、メインスレッドへ転送され、ウィンドウに表示されます。それと同時に、結果はログデータベースのスレッドへも転送され、ログデータベースが同時に更新されます。
メインスレッドによるユーザインタフェースと、オートパイロットのスレッドによる自動処理、ログデータベースの更新処理が、時々同期を取りながら、平行して動いているのが全文検索機能です。
僕は、DOS 時代に仮想機械とコンパイラからなる通信環境の開発環境を開発し ました。仮想機械というのは、平たく言えば Java の実行環境と似たようなもの です。これが Program of the air で、その中から craft という NIFTY 専用ア プリケーションが生まれました。air craft の特長は、craft が air の上で動 作するのに加え、air プログラムを使って自己を拡張できるようになっていたこ とです。
Windows 上の AirCraft には OLE オートメーションと、COM 技術による API がテストとして搭載されていますが、巡回のカスタマイズなど通信まわりのカス タマイズがやっかいでした。そこで、Ver.2.60 より、Program of the air の技 術を利用して、AirCraft 上に Air VM を実装しました。
Air VM を利用することで、PADよりきめ細かく通信部分のカスタマイズが できます。Air C コンパイラは AirCraft に内蔵で、キャビネットにソースを登 録するだけで、自動的にコンパイルして実行できます。
Air C の文法は、Program of the air の air c と同等です。サポートされる ライブラリも、通信部分などは接続や切断を除けばほぼコンパチブルとなってい ます。
追加された仕様として、AirCraft の Air C は、Windows の API や DLL を直 接呼び出すことができます。これは、関数レベルでリンクします。つまり宣言さ えあれば好きな API が呼び出せるので、Visual Basic と同等のことができま す。
Air VM で GUI を利用したい場合には、ウィンドウの処理を DLL 化すること で、Air C から呼び出すことができます。DLL 化した GUI 部分と Air VM の結 合により、とても細かなカスタマイズができると思います。
一方、Program of the air は、DOS にはウィンドウシステムやイベント処理 システムがないため、これらを独自の方法で実現していました。しかし、 Windows 自体になって、その基本的な考え方は変わらないものの、GUI との親和 性の問題があり、また上の DLL とのリンク機能が追加されたため、Air VM から はこの部分は除くこととしました。また、16bit のセグメント構造に依存してい た native 関数も同様な理由で除かれています。
新しい Air VM はマルチスレッドで動作します。つまり、複数の仮想機械を並 列で動かすことができます。それぞれの VM は固有の通信キューを持っており、 他の VM の存在を意識すること無く独自の通信処理を行うことができます。もち ろん、相互に通信しあうことも可能です。
今後、Air VM を軸として、AirCraft 標準の巡回機能のオーバーライドなどを ユーザサイドでできるようにすることも検討しています。
たとえば、現在のフォーラム電子会議室巡回部分を、自前のプログラムで置き 換えたりすることです。フォーラム移動部分にフックをかけて、最近行った フォーラムの統計を取ったり、ダウンロードした発言の統計を取ったりすること もプラグインで可能になるかと思います。これは最初のバージョンからのサポー トではありませんが、検討している事項です。
なお、Air VM は、BORG のテクノロジーの一部でもあります。