去年は1回しかこのサイトを更新できなかったと述べているうちにすでに2006年も末で今年もこのDICE v0.86リリースに合わせての年1回の更新となる。書きためていた文章もいくつかアップロードした。サイトの全体的な改装なども行いたいけれどなかなか難しい。リンク切れの修正程度が精一杯だ。
Webサイトを公開し始めて7年、このサーバに移ってきてから4年経つ。DICEも4年が経ち、かなり大規模なアプリケーションになった。4種類のサーバが1つになっている上にGUIクライアントやWebアプリケーションのスクリプトなどが入って、一人でメインテナンスするには正直言ってかなり厳しいサイズになっている。ドキュメント類の更新だけでも一仕事だ。アプリケーションのライセンスであるとか、ソフトウェアにまつわる形式的な物事に対して自分で決定し細部まで凝るのが以前は楽しみだった。
プログラミングそのものについても一貫していて、DICEのデザインについてみると、自分がかつて書いた2本の記録を読み返してみても構築的な欲求や形式へのこだわりを強く感じる。ネットワークセキュリティにも強い興味があり、DICEの設計も偏執狂的にセキュリティを追及していた。IRCサーバというのは、他の種類のサーバに比べ、一つの独立した世界を創造するという側面が非常に強い。OSからハードウェアの抽象化という機能を抜いたような物だと考えれば案外近いかも知れない。セキュリティは、作り出した世界を確固としたものとするためには必須要件である。
また、DICEを作り始めた2001年頃には、デザインパターンやeXtreme Programming、RUP、アスペクト指向などの、ポストOOとでもいうべきソフトウェア工学のトレンドが旺盛に議論されていて、その頃は私もその関係の本やドキュメントを一生懸命追いかけていた。当時の自分のスタンスはどちらかというと保守的なもので、eXtreme Programmingのような教えは米国のソフトウェアコンサルタントの新しい飯の種にすぎない、自己啓発セミナーのようで胡散臭い、といった見方だった。また、色々なプログラミング言語を勉強したり、積極的に新しいプログラミングのトレンドを追いかけたりもした。C++のテンプレートなどもその一つで、自分の3年前の文章を見るに、当時はかなり興味を覚えていたようだ。余所余所しい書き方をするのは、関心が他に移っていったからに他ならない。その徴候はこのサイトの2004年4月28日の項に現れている。
実は、DICEを作りつつも、3年以上前から別のネットワークアプリケーションを作ろうと考え色々と準備してきた。DICEにはTCP/IP ネットワークアプリケーションの全てが入っている。ファイルの送受信、通信の暗号化、多数のクライアントセッションのホスト、クライアントセッションへのグループ(チャンネル)毎へのメッセージブロードキャスト、HTTPによるファイアウォール越え、データ レコードの検索、データベースとの接続、.NETコンポーネントのホスト、GUIクライアント、Web GUI等、要はDICEというのは私にとってのWindowsネットワークアプリケーションC++ライブラリのサンプルアプリケーションだ。DICEの中に入っている物を組み替えればどんなTCP/IPアプリケーションでも高パフォーマンスを維持しつつ作れる。ツールは全て揃っている。アマチュアゲーム製作の際にやってはいけないことの筆頭として「自分用のライブラリを製作すること」というのがあるそうで、それは「いつまで経っても目的のゲームが完成しないから」だそうだ。DICEの場合、作り始めて4年で、自分用のライブラリ、ツールキットとしてはほとんど完成したのではないかというところまで、やっと到達できた。
新しいアプリケーションはもちろんDICEの部品を積極的に活用する。今度はクライアントとしての側面を強調したアプリケーションにな る予定だ。開発スタイルも、DICEのようにドキュメントも含めて完成したパッケージとするのではなく、もっとカジュアルでインクリメンタルなものにしたい。それこそbloggerがblogを毎日記すように、頻繁に少しずつ更新したプログラムをアップロードしたい。セットアップもzipアーカイブの中身を取り出すだけの簡単な物が良いかもしれない。DICEでは一旦更新するとなるとドキュメントやパッケージの更新も必要で大がかりになり、アプリケーションそのもののスピーディな更新ができなかった。気がついたら、自分が軽んじていたアジャイルソフトウェア開発のようなスタイルに惹かれていたのは何とも皮肉だ。こだわりやプライドを捨てることのなんと大変なことか。歳を取ってわかることはあると実感する。ツールの研究は十分やった。だから、こだわりを捨てて謙虚に、より多くの人に必要とされるようなソフトウェアを書きたい。応用(application)というのがキーワードだ。
しかしながら、より良いツールに対する興味も完全に失われたわけではなくて、どうやればクライアント向けの使いやすいユーザインター フェイスを作れるかについて、もうかなりの時間悩んでいる。最初に設定したユーザインターフェイスの要件は、1. ユーザが自由に改変できるものであること 2. 短期間で要素技術が陳腐化しないこと である。この要件に合致するには何を選べばよいか、悩み続けている。ユーザによる改変可能性については、ユーザインターフェイスはユーザが常に触れる物なのでユーザが好き勝手に改変できるのが最良だろうという価値判断による。改変可能性の程度としては、スキン変更といった見栄えのみの変更に留まらず、ユーザとアプリ ケーションコア間でのインターフェイスとしてのデータストリームを全てユーザが制御できるようにしたい。ある意味Unixシェルのリダイレクトやパイプの概念と同じである。プログラム全体をオープンソースにすれば原理的にこの問題は解決するが、それをせずに、アプリケーションの一定部分のみプログラマブル にしたいというわけだ。パフォーマンス上の観点からも、パフォーマンスの要る部分はネイティブコンパイル済みで、それ以外はユーザが自由に変更できるという構成は理にかなっている。何よりそんなアプリケーションがあったら私自身が欲しい。
DICEを最初にリリースしたときから管理用GUIクライアントとして添付しているDICEAdminShellはMFCで作られているC++アプリケーションである。当然ユーザによる改変は出来ないし、MFCというライブラリは今ではほとんど進歩の望めない陳腐化したテクノロジになっ てしまっている。これではいかにも面白くない。そこで、次に候補になるのは.NETだ。2004年にはDICEが.NETコンポーネントを ホストできるようにした。これはWebサーバ向けの機能として入れた物でWebアプリケーション実行が主用途だが、GUIを持ちユーザの デスクトップとインタラクトするアプリケーションも実行できる。現在のMS SQLサーバはストアドプロシージャをC#などで記述でき、同じようにDICEもCLRをホストしている。CodeDomを用いてC#などのソースコードをコンパイルしてアセンブリにした上でロードし実行する機能も入れてあるので、ユーザによるコード改変も容易である。問題は、GUIのコードを Windows Formsで開発するのが良いことなのかということだ。あと1年もすればWPF/XAMLがWindowsアプリケーションの標準ユーザインターフェイス定義言語になることは目に見えている。もう一つの可能性として、C#やC++/COMでIEコンポーネントを使う、あるいはGecko/XULでアプリケーションを構築するという道がある。IEコンポーネントの方は私自身が日常的にIEを使っていない関係上IEウィジェットの見栄えや挙動に縛られるのは個人的に嫌だし、Mozillaの方はお世辞にも開発サポートが豊富とは言い難くまたランタイムの配布サイズも大きくなってしまいそうだ。
そこで、最後に検討しているのはWeb UIである。DICEにはIEとFirefoxの双方で使えるWeb IRCクライアントを作って入れた。これはJavaScriptでタブ切り替えのUIを構成し、AJAXのHTTPリクエストではなくFlashでサーバ本体との通信を行っている。画面遷移も勿論無い。DICEにはWebサーバ機能があるので、リモート用途でなくともWeb UIを簡単に付けられるというわけだ。もちろん、通信を暗号化すればインターネットを経由したリモートアクセスのためのUIと しても使える。Web UIの短所は、右クリックコンテクストメニューがフックできない場合があること、クリップボードやサウンド再生が使えないことである。クリップボードやサウンド再生は、リモートからアクセスするのではなくローカルで動かす場合なら本体の方で処理すればよいのでそれなりに対処できるが、右クリックコンテクストメニューはブラウザ自身のメニューとの兼ね合いで問題がある。その点のみ無視すれば、基本的に、フレームバッファの内容に直接演算を適用しないと得られない特殊な視覚効果を除き、普通のデスクトップアプリケーション並みのリッチなUIをWeb UIでも実現できる。残る課題はFlashとサーバとの通信の暗号化くらいだけれども、それも目処が付いている。
そういうわけで、今考えているデザインは、UIはWebブラウザを使って、それでカバーできない部分は上記の.NET CLRホスティングでC#ソースコードを公開しユーザが改変できるようにしたいと思っている。アプリケーションのコアは今まで 通りC++で、パフォーマンスの要らない部分は可能な限り.NETの方へ回す。このページの下にある私が書いた2004年の文章では 「C++が格下の存在になりつつある」などと書いているが、実態は全然そんなことはなかったようで、Windows Vistaですら.NETは一定の範囲に留められている。DICEにPerlも組み 込んだし、要は臨機応変というわけだ。フットワークの軽さなら自信がある。
以上が今後公開しようと思っているアプリケーションの話。このサイトで他にやっているのはプログラミング関係の雑文の公開だが、一番反響があるのは意外なことにSSLの証明書を証明書ストアに入れる方法の記事だった。資料が無くて困っているのは皆同じのようである。開発者が感謝のメールをくれたりする。中には記事の範囲を超えてあれこれと相談し てくる人もいた。自分でビジネスをやっている人間は自分で問題解決して欲しいところだ。とは言っても私もFirefoxのBugzillaではオープンソースプロジェクトなのを良いことにかなり好き勝手な注文を付けたりしているので人のことは言えない。他人のリポートしたバグのプロパティを変更する権限を私は持っているので、他人のバグには介入するわで余計始末が悪い。
最近は諸々の理由で全くPCゲームをやっていない。一方で、ゲーム機のハードウェアへの興味が約2年前から非常に高まった。メインストリームPCがようやく並列プログラミングに入ろうかという時期に、ゲーム機は既に3コアとか9コアといった並列性の高いアーキテクチャをCPUに採用している。GPUの並列性はさらに高い。また、パフォーマンスがとかく軽視されがちなWebなどのプログラミングと異なり、パフォーマンスが何時の時代も追及されるのはゲームの分野である。ネットワークプログラミングも、MMOGやオンラインFPSなど一つのワールドイメージを維持しようとした場合の負荷は非常に高い。
というわけでここ2年はBeyond3DのConsole Forumに入り浸っている。ここはゲームコンソール関連のフォーラムの中では世界で一番参加者の平均年齢並びに精神年齢が 高いのではないかと思われる所で、PS3やXbox 360の開発者もよく投稿しており、メモリのレイテンシにまで気を配るハードウェアに密着したプログラミングの話題は非常に勉強になる。ゲーム機の話題は技術的な物も含め日本発のものも多く、私はよく日本語記事の英訳を提供しているのでそれが各方面から喜ばれているようだ。Beyond3D自体はリアルタイム3Dグラフィックスハードウェア専門サイトで、業界人御用達のような場所である。
IRCも約2年前からあまりやっていない。今でも海外のネット上の情報の一番濃い部分がIRCにあるという点は変わらないが、それでもWebのフォーラムが爆発的に普及してきているという印象がある。6、7年前は、日本の方が掲示板は進歩していたと思う。ところがそれ以降は海外の掲示板がCMSの進歩やPHPの台頭と相俟ってWebサイトの必需品となり、発展してきた。 imageshackとかimagevenueのようなイメージホスティングサービスも掲示板貼り付けを前提としてPHP掲示板用のBBコードを用意してくれる。海外の掲示板カルチャーは確固たるメンバー管理システムと組み合わさっていて、運用にはデータベースが必須である。CMSと親和性が高いのも当たり前だ。日本に見られる2chのような一様な匿名空間やSNSと称した出会い系サービスの作る空間、blogの散漫な空間とは一線を画した、社会的でかつ開かれた議論を行うための空間がそこにはある。
こうなってくると、TCP/IPに乗せるのはHTTP だけで良く、IRC等は要らないのではないかという疑念も生じるかも知れない。しかし、WebフォーラムとIRCの微妙な差異は依然として残っており、通信のオーバーヘッドの多寡を除けば、その差異とは、IRCではチャンネルのメンバーリストがリアルタイムに更新されメンバーの出入りがリアルタイムに宣言されるという点である。IRCはメンバーのプレゼンスをも模している。この参加者の居るライブ感という差異が残る限り、IRCが滅びることはない。一方で、Second LifeやWorld of Warcraftのような3Dの専用クライアントによるリアルタイムコミュニケーションも、10年前には失敗したが、回線品質が向上した現在はクリティカルマスに達しようかというところまで来ているようだ。それでも、無駄な部分を省いたコミュニケーションの需要は残るはずであり、むしろ参入障壁が十分に低ければシンプルなものがリッチなものを出し抜く可能性が十分にある。Web IRCクライアントにはそのような展望も込めている。
Webサイトを公開し始めて7年、このサーバに移ってきてから4年経つ。DICEも4年が経ち、かなり大規模なアプリケーションになった。4種類のサーバが1つになっている上にGUIクライアントやWebアプリケーションのスクリプトなどが入って、一人でメインテナンスするには正直言ってかなり厳しいサイズになっている。ドキュメント類の更新だけでも一仕事だ。アプリケーションのライセンスであるとか、ソフトウェアにまつわる形式的な物事に対して自分で決定し細部まで凝るのが以前は楽しみだった。
プログラミングそのものについても一貫していて、DICEのデザインについてみると、自分がかつて書いた2本の記録を読み返してみても構築的な欲求や形式へのこだわりを強く感じる。ネットワークセキュリティにも強い興味があり、DICEの設計も偏執狂的にセキュリティを追及していた。IRCサーバというのは、他の種類のサーバに比べ、一つの独立した世界を創造するという側面が非常に強い。OSからハードウェアの抽象化という機能を抜いたような物だと考えれば案外近いかも知れない。セキュリティは、作り出した世界を確固としたものとするためには必須要件である。
また、DICEを作り始めた2001年頃には、デザインパターンやeXtreme Programming、RUP、アスペクト指向などの、ポストOOとでもいうべきソフトウェア工学のトレンドが旺盛に議論されていて、その頃は私もその関係の本やドキュメントを一生懸命追いかけていた。当時の自分のスタンスはどちらかというと保守的なもので、eXtreme Programmingのような教えは米国のソフトウェアコンサルタントの新しい飯の種にすぎない、自己啓発セミナーのようで胡散臭い、といった見方だった。また、色々なプログラミング言語を勉強したり、積極的に新しいプログラミングのトレンドを追いかけたりもした。C++のテンプレートなどもその一つで、自分の3年前の文章を見るに、当時はかなり興味を覚えていたようだ。余所余所しい書き方をするのは、関心が他に移っていったからに他ならない。その徴候はこのサイトの2004年4月28日の項に現れている。
実は、DICEを作りつつも、3年以上前から別のネットワークアプリケーションを作ろうと考え色々と準備してきた。DICEにはTCP/IP ネットワークアプリケーションの全てが入っている。ファイルの送受信、通信の暗号化、多数のクライアントセッションのホスト、クライアントセッションへのグループ(チャンネル)毎へのメッセージブロードキャスト、HTTPによるファイアウォール越え、データ レコードの検索、データベースとの接続、.NETコンポーネントのホスト、GUIクライアント、Web GUI等、要はDICEというのは私にとってのWindowsネットワークアプリケーションC++ライブラリのサンプルアプリケーションだ。DICEの中に入っている物を組み替えればどんなTCP/IPアプリケーションでも高パフォーマンスを維持しつつ作れる。ツールは全て揃っている。アマチュアゲーム製作の際にやってはいけないことの筆頭として「自分用のライブラリを製作すること」というのがあるそうで、それは「いつまで経っても目的のゲームが完成しないから」だそうだ。DICEの場合、作り始めて4年で、自分用のライブラリ、ツールキットとしてはほとんど完成したのではないかというところまで、やっと到達できた。
新しいアプリケーションはもちろんDICEの部品を積極的に活用する。今度はクライアントとしての側面を強調したアプリケーションにな る予定だ。開発スタイルも、DICEのようにドキュメントも含めて完成したパッケージとするのではなく、もっとカジュアルでインクリメンタルなものにしたい。それこそbloggerがblogを毎日記すように、頻繁に少しずつ更新したプログラムをアップロードしたい。セットアップもzipアーカイブの中身を取り出すだけの簡単な物が良いかもしれない。DICEでは一旦更新するとなるとドキュメントやパッケージの更新も必要で大がかりになり、アプリケーションそのもののスピーディな更新ができなかった。気がついたら、自分が軽んじていたアジャイルソフトウェア開発のようなスタイルに惹かれていたのは何とも皮肉だ。こだわりやプライドを捨てることのなんと大変なことか。歳を取ってわかることはあると実感する。ツールの研究は十分やった。だから、こだわりを捨てて謙虚に、より多くの人に必要とされるようなソフトウェアを書きたい。応用(application)というのがキーワードだ。
しかしながら、より良いツールに対する興味も完全に失われたわけではなくて、どうやればクライアント向けの使いやすいユーザインター フェイスを作れるかについて、もうかなりの時間悩んでいる。最初に設定したユーザインターフェイスの要件は、1. ユーザが自由に改変できるものであること 2. 短期間で要素技術が陳腐化しないこと である。この要件に合致するには何を選べばよいか、悩み続けている。ユーザによる改変可能性については、ユーザインターフェイスはユーザが常に触れる物なのでユーザが好き勝手に改変できるのが最良だろうという価値判断による。改変可能性の程度としては、スキン変更といった見栄えのみの変更に留まらず、ユーザとアプリ ケーションコア間でのインターフェイスとしてのデータストリームを全てユーザが制御できるようにしたい。ある意味Unixシェルのリダイレクトやパイプの概念と同じである。プログラム全体をオープンソースにすれば原理的にこの問題は解決するが、それをせずに、アプリケーションの一定部分のみプログラマブル にしたいというわけだ。パフォーマンス上の観点からも、パフォーマンスの要る部分はネイティブコンパイル済みで、それ以外はユーザが自由に変更できるという構成は理にかなっている。何よりそんなアプリケーションがあったら私自身が欲しい。
DICEを最初にリリースしたときから管理用GUIクライアントとして添付しているDICEAdminShellはMFCで作られているC++アプリケーションである。当然ユーザによる改変は出来ないし、MFCというライブラリは今ではほとんど進歩の望めない陳腐化したテクノロジになっ てしまっている。これではいかにも面白くない。そこで、次に候補になるのは.NETだ。2004年にはDICEが.NETコンポーネントを ホストできるようにした。これはWebサーバ向けの機能として入れた物でWebアプリケーション実行が主用途だが、GUIを持ちユーザの デスクトップとインタラクトするアプリケーションも実行できる。現在のMS SQLサーバはストアドプロシージャをC#などで記述でき、同じようにDICEもCLRをホストしている。CodeDomを用いてC#などのソースコードをコンパイルしてアセンブリにした上でロードし実行する機能も入れてあるので、ユーザによるコード改変も容易である。問題は、GUIのコードを Windows Formsで開発するのが良いことなのかということだ。あと1年もすればWPF/XAMLがWindowsアプリケーションの標準ユーザインターフェイス定義言語になることは目に見えている。もう一つの可能性として、C#やC++/COMでIEコンポーネントを使う、あるいはGecko/XULでアプリケーションを構築するという道がある。IEコンポーネントの方は私自身が日常的にIEを使っていない関係上IEウィジェットの見栄えや挙動に縛られるのは個人的に嫌だし、Mozillaの方はお世辞にも開発サポートが豊富とは言い難くまたランタイムの配布サイズも大きくなってしまいそうだ。
そこで、最後に検討しているのはWeb UIである。DICEにはIEとFirefoxの双方で使えるWeb IRCクライアントを作って入れた。これはJavaScriptでタブ切り替えのUIを構成し、AJAXのHTTPリクエストではなくFlashでサーバ本体との通信を行っている。画面遷移も勿論無い。DICEにはWebサーバ機能があるので、リモート用途でなくともWeb UIを簡単に付けられるというわけだ。もちろん、通信を暗号化すればインターネットを経由したリモートアクセスのためのUIと しても使える。Web UIの短所は、右クリックコンテクストメニューがフックできない場合があること、クリップボードやサウンド再生が使えないことである。クリップボードやサウンド再生は、リモートからアクセスするのではなくローカルで動かす場合なら本体の方で処理すればよいのでそれなりに対処できるが、右クリックコンテクストメニューはブラウザ自身のメニューとの兼ね合いで問題がある。その点のみ無視すれば、基本的に、フレームバッファの内容に直接演算を適用しないと得られない特殊な視覚効果を除き、普通のデスクトップアプリケーション並みのリッチなUIをWeb UIでも実現できる。残る課題はFlashとサーバとの通信の暗号化くらいだけれども、それも目処が付いている。
そういうわけで、今考えているデザインは、UIはWebブラウザを使って、それでカバーできない部分は上記の.NET CLRホスティングでC#ソースコードを公開しユーザが改変できるようにしたいと思っている。アプリケーションのコアは今まで 通りC++で、パフォーマンスの要らない部分は可能な限り.NETの方へ回す。このページの下にある私が書いた2004年の文章では 「C++が格下の存在になりつつある」などと書いているが、実態は全然そんなことはなかったようで、Windows Vistaですら.NETは一定の範囲に留められている。DICEにPerlも組み 込んだし、要は臨機応変というわけだ。フットワークの軽さなら自信がある。
以上が今後公開しようと思っているアプリケーションの話。このサイトで他にやっているのはプログラミング関係の雑文の公開だが、一番反響があるのは意外なことにSSLの証明書を証明書ストアに入れる方法の記事だった。資料が無くて困っているのは皆同じのようである。開発者が感謝のメールをくれたりする。中には記事の範囲を超えてあれこれと相談し てくる人もいた。自分でビジネスをやっている人間は自分で問題解決して欲しいところだ。とは言っても私もFirefoxのBugzillaではオープンソースプロジェクトなのを良いことにかなり好き勝手な注文を付けたりしているので人のことは言えない。他人のリポートしたバグのプロパティを変更する権限を私は持っているので、他人のバグには介入するわで余計始末が悪い。
最近は諸々の理由で全くPCゲームをやっていない。一方で、ゲーム機のハードウェアへの興味が約2年前から非常に高まった。メインストリームPCがようやく並列プログラミングに入ろうかという時期に、ゲーム機は既に3コアとか9コアといった並列性の高いアーキテクチャをCPUに採用している。GPUの並列性はさらに高い。また、パフォーマンスがとかく軽視されがちなWebなどのプログラミングと異なり、パフォーマンスが何時の時代も追及されるのはゲームの分野である。ネットワークプログラミングも、MMOGやオンラインFPSなど一つのワールドイメージを維持しようとした場合の負荷は非常に高い。
というわけでここ2年はBeyond3DのConsole Forumに入り浸っている。ここはゲームコンソール関連のフォーラムの中では世界で一番参加者の平均年齢並びに精神年齢が 高いのではないかと思われる所で、PS3やXbox 360の開発者もよく投稿しており、メモリのレイテンシにまで気を配るハードウェアに密着したプログラミングの話題は非常に勉強になる。ゲーム機の話題は技術的な物も含め日本発のものも多く、私はよく日本語記事の英訳を提供しているのでそれが各方面から喜ばれているようだ。Beyond3D自体はリアルタイム3Dグラフィックスハードウェア専門サイトで、業界人御用達のような場所である。
IRCも約2年前からあまりやっていない。今でも海外のネット上の情報の一番濃い部分がIRCにあるという点は変わらないが、それでもWebのフォーラムが爆発的に普及してきているという印象がある。6、7年前は、日本の方が掲示板は進歩していたと思う。ところがそれ以降は海外の掲示板がCMSの進歩やPHPの台頭と相俟ってWebサイトの必需品となり、発展してきた。 imageshackとかimagevenueのようなイメージホスティングサービスも掲示板貼り付けを前提としてPHP掲示板用のBBコードを用意してくれる。海外の掲示板カルチャーは確固たるメンバー管理システムと組み合わさっていて、運用にはデータベースが必須である。CMSと親和性が高いのも当たり前だ。日本に見られる2chのような一様な匿名空間やSNSと称した出会い系サービスの作る空間、blogの散漫な空間とは一線を画した、社会的でかつ開かれた議論を行うための空間がそこにはある。
こうなってくると、TCP/IPに乗せるのはHTTP だけで良く、IRC等は要らないのではないかという疑念も生じるかも知れない。しかし、WebフォーラムとIRCの微妙な差異は依然として残っており、通信のオーバーヘッドの多寡を除けば、その差異とは、IRCではチャンネルのメンバーリストがリアルタイムに更新されメンバーの出入りがリアルタイムに宣言されるという点である。IRCはメンバーのプレゼンスをも模している。この参加者の居るライブ感という差異が残る限り、IRCが滅びることはない。一方で、Second LifeやWorld of Warcraftのような3Dの専用クライアントによるリアルタイムコミュニケーションも、10年前には失敗したが、回線品質が向上した現在はクリティカルマスに達しようかというところまで来ているようだ。それでも、無駄な部分を省いたコミュニケーションの需要は残るはずであり、むしろ参入障壁が十分に低ければシンプルなものがリッチなものを出し抜く可能性が十分にある。Web IRCクライアントにはそのような展望も込めている。
コメント
コメントを投稿