アカウント名:
パスワード:
タレ込み記事そのものが単に「煽り」だからでしょう。 ストーリーごと「フレームのもと(-1)」だよこりゃ。azkeyは どうも「崩壊」という言葉に引きずられてるね。Donの発言を MSの(傲慢な)プロパガンダだとみなしているだけ。 記事の内容をまったく理解していない。それを通過させた wakatonoも同罪。 編集者はもうちょっと、コメントを育てる記事づくりをして欲しいなぁ。
言ってる事は充分納得できる内容だ。うちとこの修論の研究で、非常に大きい XMLデータをhttpで受信する際に、送信側と受信側が並列に動作できる筈なのに、 送信側でContent-lengthをいちいち計算してしるまうが故にこの二つの処理を 重ねる事ができず、処理能力が低下してしまう、というのがあった。何故httpを 使うかというとSOAPベースだからなのだが、こういった細かい事例があって やはりhttpに依存する訳にはいかん、いかんけど防火壁問題が… と阿呆らしい状況になっている。Donの発言は「いい加減こんな阿呆らしい事 やめようぜ!」と言っているのだと僕は受け止めている。
SOAPすなわちHTTP依存だというのは私の思い込み故失礼しました。 アプリとしては、大きな行列・気象やゲノム等の巨大データベースなど。 こういったデータを分散環境で移送してガンガン計算させる事を想定している。 ストリーム性は通信時間を隠蔽して全体の計算性能を稼ぐ意味で効いてきます。 (修論ではシリアライズ([生データ→XML]⇒(ネット)⇒[XML→生データ]の変換) の部分の処理の負担がデカいのを気にしていました)んで、こうした枠組を 「よくあるレイヤ」にのっける事が重要なのだそうな。 そうでなくても、防火壁絡みで運用が面倒な事に なっているのでHTTPにしておきたいなぁ、というのがあるのだそうです。
でも、やっぱり無茶だよね。そもそも僕は何故こんな状況(HTTPだけが何故 通過でき、どうしてそこに何でもかんでもつぎこむ)事になったか、 歴史的経緯がよくわかっていないので何ですが…。「側面からの問題」として 挙げられている点がまさに心配です。あと、httpdが入力の全てをひとまず面倒みなきゃ なんないってのがなんとも…。
件の修論ではそうやって性能を稼ぐ実験をしています。送信されるデータはXMLなので、 データ終端を受信側で検出する事もできます。問題は、RFC違反だという事だそうです。 Apache-SOAPを使ったナイーブな実装に比べてかなりの性能向上があった。 巨大行列データをXMLエンコーディングしての転送での実験です。
詳しい話は 白砂 [titech.ac.jp] 君の研究ページにそのうち書かれるでしょう。
プロトコルであれば、スクリプトなどよりよっぽど厳密にセキュリティに気をつけ、 規格を定めなければならない(そうですよね?)のに、スクリプト程度で話にもな
この表現自体がかなり問題ありと思うのはおれだけかな。ActiveX [ascii24.com] をスクリプト関連と言い切ってしまうのも謎だし、プロトコル云々にしても、どの階層で何を保証するか(あるいはしないか)というあたりの話を意識できてるのか
この論理が理解不能。技術的な話題について、発言内容をさしおいて所感を書くことに何の意味が? 非論理的に見下した態度のどこに正当性が? ……これはいけないことであるので、反省してください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
つーか (スコア:1)
他社のサービスに期待じゃなくて、みんなで作りましょうって話じゃないの?
反射神経だけの人多いなぁ
Re:つーか (スコア:4, 参考になる)
タレ込み記事そのものが単に「煽り」だからでしょう。 ストーリーごと「フレームのもと(-1)」だよこりゃ。azkeyは どうも「崩壊」という言葉に引きずられてるね。Donの発言を MSの(傲慢な)プロパガンダだとみなしているだけ。 記事の内容をまったく理解していない。それを通過させた wakatonoも同罪。 編集者はもうちょっと、コメントを育てる記事づくりをして欲しいなぁ。
言ってる事は充分納得できる内容だ。うちとこの修論の研究で、非常に大きい XMLデータをhttpで受信する際に、送信側と受信側が並列に動作できる筈なのに、 送信側でContent-lengthをいちいち計算してしるまうが故にこの二つの処理を 重ねる事ができず、処理能力が低下してしまう、というのがあった。何故httpを 使うかというとSOAPベースだからなのだが、こういった細かい事例があって やはりhttpに依存する訳にはいかん、いかんけど防火壁問題が… と阿呆らしい状況になっている。Donの発言は「いい加減こんな阿呆らしい事 やめようぜ!」と言っているのだと僕は受け止めている。
ニーズがあればそのうち作られると思う・・・けど (スコア: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"の値が計算できそうだが.
それだと送信データが大きくなるのが,問題となりそうだ.
Re:つーか (スコア:1)
ただ、ActiveX等のスクリプト関連でトラブルが起こり、非常に被害を受けているユーザーさんの話を環境上非常によく聞ので、「うざってぇ」と言う気持ちが煽りっぽく滲み出してしまったものはあるかも知れません。
「こんなもの放置したままで、よくもこんな発言が出来るな?」
と。そういう発言する前に、もっと足下見て欲しい、と思ったわけです。
HTTPを「インターネットのゴキブリ」と喩える辺り、それこそお前らはどうなんだ、と。底辺のユーザーさんの現状を知っていると、思ってしまうわけです。
少し慣れていれば自衛出来るかも知れませんが、マイクロソフトのおかげでかなりの被害を受けた方も相当いらっしゃるのですよ。
まあ、プロトコルとスクリプトでは全く別の話だ、と言ってしまえばそれまでかも知れませんが。
泥棒に「お前、盗みなんかしちゃいけないぞ」と言われたら、その内容の是非はともかく、私は「はぁ?」と思うのです。
「こんな阿保らしいことやめようぜ!」と言いながら、マイクロソフトがそれよりさらに阿保らしいことをたくさんしているのがどうしても目についてしまいます……
私自身が他の方々に比べると全く知識足らずであるのはわかっているので、下手に何か書くとフレームの元になると思い、敢えて記事の内容には深く触れず、自分の所感のみ書いたのですが…… それがいけないことであるというのなら、今後反省致します。
Re:つーか (スコア:0)
「過去の所業」が正論を揶揄する免罪符にはならないよ。
タレ込む前に一息ついて頭冷やして自分の文章読み返しな。
Re:つーか (スコア:1)
プロトコルであれば、スクリプトなどよりよっぽど厳密にセキュリティに気をつけ、規格を定めなければならない(そうですよね?)のに、スクリプト程度で話にもならない問題をびしばし引き起こしててどうする、って意味です。
なんにせよ、私のタレコミに考えが足らなかったのは、認めます。 もう少し頭冷やしてからたれ込むか、そもそもタレ込まないようにします。
Re:つーか (スコア:0)
この表現自体がかなり問題ありと思うのはおれだけかな。ActiveX [ascii24.com] をスクリプト関連と言い切ってしまうのも謎だし、プロトコル云々にしても、どの階層で何を保証するか(あるいはしないか)というあたりの話を意識できてるのか
Re:つーか (スコア:0)
なんでそこまで要求するのか謎、他人様の発言を読解する能力がsるのか謎、なんでこんなのにレスつけてるのか謎。
Re:つーか (スコア:0)
この論理が理解不能。技術的な話題について、発言内容をさしおいて所感を書くことに何の意味が? 非論理的に見下した態度のどこに正当性が? ……これはいけないことであるので、反省してください。