memo/20070618

リンク	備考
Google のソフトウェア・エンジニアリング

/.J 記事から漂着。参考になるっていうか、ならないっていうか、
優秀な人材がそろっている企業でないと実行できなそうな方針ですね。
「Google では、偉い人ほどコードを書きまくっている」とか。

リモート処理でのデータ表現で循環参照

RPC等のリモート処理、SNMPでのデータ取得等で構造化データをどう送受信するか、という問題がありまする。
近年、なんとなくこの問題に興味があってちょこちょこと勉強しているわけです。

リモート処理の種類	データ表現
DCEのRPC(IBM HP MS方式)	NDR
ONCのRPC(Sun方式)	XDR
SNMP	BER(ASN.1は表記法)

で最近は「Webサービス」とかでXMLっていうかSOAPっていうかそういうのがあるわけですが

渡したいデータが循環参照を含む場合、どうすればよかろうね？

下記のような話題があります。

• 本質的にそんなデータを渡す必要があるのか
• 呼び側のバグで渡されたときにライブラリはどう対処すべきか

というか、深さ優先符号化と幅優先符号化の比較などという、基本的な部分からちゃんと勉強せねばだめポです。orz

頭にヘッダ、そのあとに可変部分が続く電文構造で、ヘッダにおいて下位データを参照する部分を、プログラム中はポインタ、電文ではオフセット＋１、などと表現するとわりといい感じの符号化方式になる、などと考えているのですが、はて、これでは幅優先で符号化されてると「ポインタを配列の先頭とみなす」ことでうまい具合にいけそうですが、深さ優先では無理です。

XMLは深さ優先符号化ですよね。XMLのパーザーは「このタグ来たヨ」というイベントドリブン方式にすると、無限の長さに対応できるということは分かります。
でもそれって結局、送信側も受信側も、有限長の配列方式はダメダメで可変長リンクリストで持つようにすべし、ってこと？

結局は、短い（簡潔な）電文をやり取りしたい場面と、長い（表現力の豊富な）電文をやり取りしたい場面とを切り分けして、適切な方式を使い分けないといけないっつーことでしょうか。
線引き問題...マネージャがヤマを張るべき問題のひとつに入るのか。

どっかの文書で、「リモート処理の電文の問題はXMLの登場により一気に解決」とか言ってるのがあったけど、別になんも解決してないじゃんと改めてオモタ。

脈絡なく書籍のブックマーク

google:こども大変時代

産経の「こども大変時代」が本になったそうな。