Sockletの配備方法の変更

GPSS1では、Sockletの配備までGPSSサーバで面倒を見ていました。
つまり、接続一発目のコマンドはGPSSサーバ自体で解釈し、その後にSockletに引き渡す、というようないろいろとややこしい処理が入っていました。
GPSS2ではその部分をばっさりカット。
GPSSサーバは純粋にソケットの待ち受けのみに徹することになりました。

ではどうするのかと言いますと、GPSSサーバには必ず1つだけデフォルトのSockletを登録するようにして、接続を受け付けると有無も言わさずそのデフォルトのSockletにクライアントを預け、コマンド処理はそちらに任せてしまう、といった処理になりました。

このデフォルトのSockletを、特別にSockletDeployerと呼びます。
SockletDeployerは、必ずSockletDeployerインターフェースを実装する必要があります。
また、SockletDeployerインターフェースを実装したクラスをSeasarのDICONに登録すると、自動的にGPSSサーバにDIされます。

ですので、GPSS1では接続後一発目のコマンドについてはGPSSの仕様として限定されてしまっていましたが、GPSS2ではSockletDeployer次第で如何様にも書けるようになりました。

と言うわけで、HTTPの受け答えも書けると思います。>> HTTPポーリングによる接続
また、2chのスレの方で話も出てた、FACEs用のアプリケーションをがっつり移植ができちゃうSockletDeployerも作っちゃおうかな、なんて野望も抱いてたりしますw