アドオンを繋げる

　Nuke タイプの惚れるスペックに、

• コア機能はほとんどなく、モジュールで実装される
• どのモジュール（アドオン）が入っているかはユーザーによって異なる
• にも関わらず、モジュール間のタイアップが求められる
• あろうことか、モジュールの複製サポートがデフォルト化しつつある

　というんがある。
　一般的にいうモジュール間通信は、パッケージソフトや納品するソフトでは、手元で完全に組み上げてから納めるじゃろーけー*1、普通はそこまで大変ではない。がっちり相手を掴んで、直接通信すりゃあええだけ。
　しかもこれは最近の「インスタンスを掴んで、メソッドを叩く」というコードスタイルにもガッチリ一致する。

　Nuke 系が熱いんは、相手が掴めんことね。相手がおるかどうか、どんな相手がおるか分からんけんね。

• モジュールAが通信を取りたいモジュールBが入っとるかどうか分からん
• モジュールBをユーザーは別モジュールでリプレスしたいと考えてとる
• モジュールAとモジュールBの通信を妨害したいと思わないものの、フックしたい人はいる
• （特定の通信に限り、妨害したい人はいる）

　ゲーム！ゲームじゃないか！
　こんなんじゃけー、このネタでXCコミュが盛り上がるときは、ゲームのMODがタイアップの方法を論じるときとよく似とる。ただ、ゲームプログラムではMODでなくても、相手が何人おるんか、もしくはおらんのか分からん（アスペクト的な）通信が日頃から頻発しとるんで、メッセージングは低レベルでも昔から色々好まれとるのに対して、Webは結構ガッチリしたプログラムが好まれる模様。なので、過去何度かあったモジュール間通信の議論も、だいたい直通信（掴んで通信）に落ち着いてる。

　まぁつまり、通信というのはちょっとバタくさいというか低レベル機能なところがあって、ゲームプログラムは元々ちょっとバタくさいのでみな受け入れとるんじゃけど、 Web は明快なコードをスパッと書くクールなスタイルなんよね。なので不明快な通信というものを扱ううえで、どうしようかというのが議論になる。
（通信自体は普通にやりゃーできることはみんな分かってる）

　とはいえ、アドオン間の通信は、通常の通信をモデルにしたものを使うのが、今のところ一番ええと思う。それこそポート指定してメッセージ流して……

　相手がおらんでもメッセージを出せる（ブロードキャストメッセージ）し、フックも簡単に実装可能で、ここでいうモジュールBのリプレスも簡単にできる上に、並列処理にも対応できる。言語によっては仕様じゃし、なにより、今も昔も一般的な方法なんで、世代に関係なくプログラマの間で簡単に統一認識を持てそうなんがいい。なんかのカーネルから基本構造引っぱってくりゃあええし。 BeOS がええらしい。

　あと、PHPのような動的な言語なら、ランタイムでクラスを生成して、オブジェクトハンドリングの操作感も提供できるんではなかろうか。コアでやることではないけど、SDKで提供されていいライブラリかもしれん。

　そうすれば低レベル通信とPHPらしいコーディングと両立できるはず。

*1:こういった立場ではデリゲートの定義側に回る必要がないのも同様の理由