日々の破片

_ おいら（という一人称を選ぶというコンテキストの文章なのだ）とXML

1997年だと思うんだけど、もちょっと早い（ってことはないだろう）かも。

どっちが早いかは微妙だけど、とある協議会とDCOMのメーリングリスト（と言っても読んでるだけだけど）のどっちかでXMLが話題になりつつあったのであった。実装としてはIE4の最初のXMLパーサが出現したころだ。

で、DCOMのMLのほうでは、ジョナサンボーデンってやつがSMTP上でXMLを利用したRPCについていろいろ書いていた。で、COMの型のシリアライゼーションとか、それに対してDCOMでいいじゃんとかいう意見とか、IISのDCOMプロクシ（名前忘れた）がバギーだとかいろいろあったりしたのだが、

・HTTPのように、TCP/IPの上の非常に薄いプロトコル上に乗っけたアプリケーションプロトコロル

・データは文字列ベースでかつパーシングが簡単か、不要

ということを自分が関係するソフトウェアの通信インフラとして考えていた僕は、ジョナサンボーデンのアイディアがすごく気に入った。

最初の点はブラックボックスを可能な限り薄くしたいということだ。本当はUDPが良いのだが（とその頃は信じていたし今でも時々は思う）、どうも再試行のアルゴリズムをどうやっても輻輳が起きてしまう（再試行の再試行の再試行に対してNAKが出てきて再試行してのような状態）という問題があったので、どうあがいても問題があるのなら、何も考えずにTCPの実装に任せてしまえというのもある。で、TCP上に乗せると決めればデバッグツールとしてブラウザ（サーバー側にとっては）とIISみたいなサーバ（クライアント側にとっては）が出来合いであるわけだから、HTTPをその上に被せれば良さそうだとなった。

で、データをどうするかだけど構造が複雑だったりするからバイナリをいろいろいじることも考えたりもするわけだが、プロトコル決めるところで出来合いのものをデバッグ用に使おうとしているということから、あまり外れたものじゃ具合が悪いな、CSVってのはネストした構造を表現するのが大変だし、とか考えていたところにジョナサンボーデンのアイディアがあって、そうかXMLか、と納得したのであった。それに確かにXMLであれば、要素を決めておけばオレ様RPCの実装も極めて単純に済む。全部文字列だからVBScriptみたいなへっぽこ言語（今はそんなにへっぽこじゃないけど、その頃はとてつもなくへっぽこであった）でもテスト用サーバアプリケーションくらいささっと書けるし、それでいいや、てな感じだ。

つまり、HTTP＋XML＝オレ様RPCという公式は、あの頃、誰でも考えていた。で、大声で先頭を走ったのがXML-RPCで、がつんがつんと製品として規格化をやっていったのがSOAPだということだ。だからSOAPは最初はMSのオレ様ORPC（COMのデータ型だけ考えてた――XDRを使って――で、BizTalkに雰囲気が残っていたり）でその後にIBMが入ってきたりしてまっとうなRPC（ORPCではなくなっていたり）の仕様となる。その一方、辺境の地で僕はオレ様の世界で走り出していた。

ちなみに、RPCのインフラとしてHTTPを実際に使うとなると、ネイグルアルゴリズムやらHTTPサーバ側のバッファリングだとか、コネクションのキープアライブだとかが出てくるのだが、そういうものは最適化するときに考えることにすれば良いので無視。

というようなところから出発したもので、僕にとってはスキーマはオレ様スキーマで良いというか、そもそもスキーマは本当にメタなところにしか存在しない。だからXDRも、XML-RPCも、無視だ。だってどの要素がどの型かはスキーマ(DTDで十分)を切った時点でわかってるわけだし。その仕様に影響されるのはオレ様の世界だけだからね。

当然、そんな時期に実装したわけだから、スキーマコンパイラなんて気の利いたものはまだ存在しないから、自分でIE4のDOMをベースに実装することになる。だいたい、IE4のDOMだと空白の扱いや大文字小文字の扱いがVBルールだったりしたからどうにもならんのだな。で、さらにIE4を乗せられない箱もあったりするわけで、しょうがないので、IE4のDOMとAPI互換のCOMのDLLを作ったり。さらにIISが乗らないボックスがあって、これもしょうがないのでVBScriptをホストする（これは、IE3.2が乗っていればくっついているわけだし）VBScriptから見たらIIS互換のHTTPサーバをでっち上げたり（ということは、このサーバに関してはNT4のOption pack以降のことだからもっと時期は遅いな）。このオレ様HTTPサーバ（ASP互換もどき）は結構重宝した。

で、それがレガシーになったから、SOAPが出てきてもスキーマコンパイラが出てきても、ほとんど関係がなかったのだ。というか、SOAPに合わせる必要性も必然性もないし。とは言え、本当は使えるものは使いたいのだが、どうしようもなくNT4SP4のままの箱とかがあったり、IEのバージョンを4以降にできなかったりする箱が残っている限りはどうにもならんな、という側面があったのも事実ではある。で、MSの世界とは言え、まさしく異機種混交なので（IE3とIE4、IISの有無、その他もろもろ。最後にはNT3.51やCE2.xまで相手にした）、HTTP＋XML＝RPCは確かに良い選択かも知れない。使えるところではIISや（まともになった）DOMDocumentが使えたのも事実だし。

で、結局1999年までにはそうやって直接パーシングする文化がチームに根付いてしまった。当然、スキーマコンパイラを使う習慣がチームに無いってのがいろんな意味で開発の方向を決めてしまう。だって、スキーマコンパイラの仕様を調べなくても自分でパーサいじれば何でもできてしまうわけで、ある意味、非常に効率が良い。スキーマ定義も人間が了解できれば良いわけで（ということはバリデーションも使っていなかったり。というのはパーサがそのスキーマを非サポートだったりする場合もこれまた異機種混交なのであるからだ）いい加減なものだ。そんなやり方だから、21世紀になってスキーマがDTDからWXSやRELAX NGに変わっても（というか、好き勝手なスキーマを各自がいろいろ使っている時点で統一もへったくれもないが、僕はそれで全然OKだと思っている）相変わらずSAXやらDOMやらを直接いじくるのが主流であったり。さすがにそろそろスキーマコンパイラくらい使おうぜと幾つか使ってみたが、既に技術基盤として直接パーサとインターフェイスする文化があるからどうやっても、汎用ってのは汎用だよね、という結論にならざるを得ない。結局、自分で書いたほうが早いし、きめ細かいし、微妙な調整が可能だし。っていうか、SAX好きだし。で、相変わらず人によってDTDでスキーマきったり、WXS使ったり、RELAX NGだったりばらばらだったり。

というわけで、限りなくボヘミアンにやっているのが実情だったり。

#だから、SOAP一押しと言われても、ちょっと微妙かな。.NETヘテロ(何書いてんだか。逆じゃん)だけのシステムであだったりすれば、文句なし一押しではあるけど。というか、そういうシステム（もあるわけで）では当然のようにそうなんだけど。特にVS.NETを開発標準とすれば、スキーマコンパイラを意識する必要すら無いし、スキーマはお絵かきで書けるし。で、選択の問題としても、多少の速度遅延があっても（むにゃむにゃ）Remotingや相変わらずなDCOMみたいなむにゃむにゃを使うなんて危険なことはできないわけで、当然のようにSOAPを使うことになる(XMLデシリアライゼーションが遅い？ そんな時は直接パーシングで決まりだ)。

というわけで、Indigoが楽しみだ。

_ で、

なんて書いてあらためていろいろ巡回してたら、sumimさんがRubyとIndigoとSmalltalkが並列している妙な引用を書かれていた。

で、読みに行ったらドンボックスがRubyを学ぶべき（またはSmalltalkを学び直す）時が来たれりとか書いている。で、静型付け言語とIDE――これが無ければダメダメよ、というコメントが付いていて、さらにYoshikiさんがちょっと妙な反論（JavaにしろC++にしろ未宣言のインスタンス変数はエラーになるからその点が妙だ。C++だと未初期化のローカル変数がらみのバグはありえるからその意味かな？ それにリファクタリングしてそんなエラーが入るってことは有り得ないと思う）をしていたり。でも主張はわかる。どっちも。

それにつけてもドンボックスは、オブジェクトからメッセージ（でも、Indigoのメッセージって抽象的なメッセージじゃなくて物理的なメッセージだと思うんだけど違うのか？）に転進を遂げたんだったな。

いずれにしろ、オブジェクトであろうがメッセージであろうが、仕様のバグを前にすれば、どちらもバギーなプログラムとなることだけは事実だけど。