アカウント名:
パスワード:
タレ込み記事そのものが単に「煽り」だからでしょう。 ストーリーごと「フレームのもと(-1)」だよこりゃ。azkeyは どうも「崩壊」という言葉に引きずられてるね。Donの発言を MSの(傲慢な)プロパガンダだとみなしているだけ。 記事の内容をまったく理解していない。それを通過させた wakatonoも同罪。 編集者はもうちょっと、コメントを育てる記事づくりをして欲しいなぁ。
言ってる事は充分納得できる内容だ。うちとこの修論の研究で、非常に大きい XMLデータをhttpで受信する際に、送信側と受信側が並列に動作できる筈なのに
SOAPすなわちHTTP依存だというのは私の思い込み故失礼しました。 アプリとしては、大きな行列・気象やゲノム等の巨大データベースなど。 こういったデータを分散環境で移送してガンガン計算させる事を想定している。 ストリーム性は通信時間を隠蔽して全体の計算性能を稼ぐ意味で効いてきます。 (修論ではシリアライズ([生データ→XML]⇒(ネット)⇒[XML→生データ]の変換) の部分の処理の負担がデカいのを気にしていました)んで、こうした枠組を 「よくあるレイヤ」にのっける事が重要なのだそうな。 そうでなくても、防火壁絡みで運用が面倒な事に なっているのでHTTPにしておきたいなぁ、というのがあるのだそうです。
でも、やっぱり無茶だよね。そもそも僕は何故こんな状況(HTTPだけが何故 通過でき、どうしてそこに何でもかんでもつぎこむ)事になったか、 歴史的経緯がよくわかっていないので何ですが…。「側面からの問題」として 挙げられている点がまさに心配です。あと、httpdが入力の全てをひとまず面倒みなきゃ なんないってのがなんとも…。
件の修論ではそうやって性能を稼ぐ実験をしています。送信されるデータはXMLなので、 データ終端を受信側で検出する事もできます。問題は、RFC違反だという事だそうです。 Apache-SOAPを使ったナイーブな実装に比べてかなりの性能向上があった。 巨大行列データをXMLエンコーディングしての転送での実験です。
詳しい話は 白砂 [titech.ac.jp] 君の研究ページにそのうち書かれるでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
つーか (スコア:1)
他社のサービスに期待じゃなくて、みんなで作りましょうって話じゃないの?
反射神経だけの人多いなぁ
Re:つーか (スコア:4, 参考になる)
タレ込み記事そのものが単に「煽り」だからでしょう。 ストーリーごと「フレームのもと(-1)」だよこりゃ。azkeyは どうも「崩壊」という言葉に引きずられてるね。Donの発言を MSの(傲慢な)プロパガンダだとみなしているだけ。 記事の内容をまったく理解していない。それを通過させた wakatonoも同罪。 編集者はもうちょっと、コメントを育てる記事づくりをして欲しいなぁ。
言ってる事は充分納得できる内容だ。うちとこの修論の研究で、非常に大きい XMLデータをhttpで受信する際に、送信側と受信側が並列に動作できる筈なのに
ニーズがあればそのうち作られると思う・・・けど (スコア:2, 興味深い)
側面から見たHTTPの問題は、おかげさまで防火壁のデフォルト穴が既に壁のサイズ並にでかくなってること。
正面から見た問題 - Content-length等のプロトコル上の不便さ - は、それ自体が変更されるか、そもそもHTTPのレイヤーでストリームラインな処理を期待しない方向に進むかな・・・と思うんだけどどう思う?
SOAPにおけるHTTPの位置付けはあくまでrouterの1つで、ほかのrouter基盤にもストリーム性が要求されているわけではないよね?
ちなみに、SOAPもHTTPも全くもってトランザクション性を考慮したプロトコルではないので、結局その上にトランザクションを実現するプロトコルを実現しようとする動き [oasis-open.org]があったりすることだし、もしストリーム性が必要だったら同じようにそのレベルで実装してね・・・って感じになるのかな?
あと、普段そういう要求を感じないので、想像すらできないので教えて欲しいんだけど、大容量でダイナミックに生成されるデータを、実時間内に並列度上げて処理する必要のあるアプリケーションって、メディア系以外に例えば何がある?
いずれにせよ、「Segway開発したぜ、こいつはすごいぜ!」って言われても、それが走れる道がないことにゃ、そいつは普及しない様に、HTTPっていう既にできた道の存在はやっぱ大きいんでないかな~?
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:1)
SOAPすなわちHTTP依存だというのは私の思い込み故失礼しました。 アプリとしては、大きな行列・気象やゲノム等の巨大データベースなど。 こういったデータを分散環境で移送してガンガン計算させる事を想定している。 ストリーム性は通信時間を隠蔽して全体の計算性能を稼ぐ意味で効いてきます。 (修論ではシリアライズ([生データ→XML]⇒(ネット)⇒[XML→生データ]の変換) の部分の処理の負担がデカいのを気にしていました)んで、こうした枠組を 「よくあるレイヤ」にのっける事が重要なのだそうな。 そうでなくても、防火壁絡みで運用が面倒な事に なっているのでHTTPにしておきたいなぁ、というのがあるのだそうです。
でも、やっぱり無茶だよね。そもそも僕は何故こんな状況(HTTPだけが何故 通過でき、どうしてそこに何でもかんでもつぎこむ)事になったか、 歴史的経緯がよくわかっていないので何ですが…。「側面からの問題」として 挙げられている点がまさに心配です。あと、httpdが入力の全てをひとまず面倒みなきゃ なんないってのがなんとも…。
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:1)
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:1)
それより"Content-Length:"のヘッダフィールドは,必須ですか?
送信サイズ不明で,"Content-Length:"ヘッダフィールドなし
で送信してしまうという手もありますが.
(受信側は,全体量が分からないのが困るが,受信自体は可能.)
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:1)
件の修論ではそうやって性能を稼ぐ実験をしています。送信されるデータはXMLなので、 データ終端を受信側で検出する事もできます。問題は、RFC違反だという事だそうです。 Apache-SOAPを使ったナイーブな実装に比べてかなりの性能向上があった。 巨大行列データをXMLエンコーディングしての転送での実験です。
詳しい話は 白砂 [titech.ac.jp] 君の研究ページにそのうち書かれるでしょう。
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:0)
>
>それより"Content-Length:"のヘッダフィールドは,必須ですか?
>送信サイズ不明で,"Content-Length:"ヘッダフィールドなし
>で送信してしまうという手もありますが.
Content-Length無しでKeep-Aliveできたっけ?
Connecti
Re:ニーズがあればそのうち作られると思う・・・けど (スコア:1)
それだと扱う行列の大きさが送信前に分かっているので,
行列の要素(数値)を空白でパッティングした固定長と
すれば,"Content-Length"の値が計算できそうだが.
それだと送信データが大きくなるのが,問題となりそうだ.