アカウント名:
パスワード:
CGIによるWBメールが生まれたころには、送信ボタンを押してから画面の更新が完了するまでに数秒間が経過してしまい、それから操作を行ったとしても中止操作が間にうものではありませんでした。いまでは、中止ボタンを押すのが間に合ってしまうのですね。WEBブラウザの動作もずいぶん早くなったのだと驚かされます。
でけぇ釣り針だな
荒しは不当でしょ。昔は（今でも？）Webメールのシステム構築の仕方によって異なっていたものをたった一つの要素（ブラウザの描画速度の向上）を要因として向上した、なんてでかい釣り針以外の何者でもないでしょ。しかも実際は仕組みにあんま関係ないし。
cgi内からsendmail(qmail)呼び出ししてからhtml送信する様なごく単純なシステムからフロントエンドhttpサーバー複数持ち＆バックエンドに複数のsmtpサーバー持ってキューバッファにある送信待ちメールを定量的に送信するシステムまで様々。# ちょっと色物ではローカルのメーラと同じ事（設定されたsmtpサーバに#
>最近の主流
主流ではなくまだ「次世代」と呼ぶべきでしょうけど、「継続ベースのWebアプリ/Webサーバ」だとmod_hogeやServletどころかひとつの「関数」の途中で処理を一時中断というか待たせることが出来て、しかもそのあいだにユーザへのレスポンスを返すことが出来たりします。
デスクトップアプリでいう「ダイアログ」のような振る舞いを、凝ったコーディングをせずに(Request/Responseペアやイベント駆動を意識する必要なく)、やれてしまいます。VBでDialogを出したり、JavaScでAlertを出したりするとき、特にデフォルトのお仕着せダイアログを出すだけなら、result = hogeDialog.show();とか1行を「呼び出す」だけで済みます。(呼び出されるコールバックを意識せずに済む)こういうコーディングがWebアプリでも出来るってこと。
で、これだと、私も良くは知りませんが多分、いわゆる起動オーバーヘッドは減ると思います。なんせ立ち上げっぱなしなのですから。
ただし引き換えというか当然の結果として、その関数を立ちあげたまま保留しとくためのコスト(主にメモリ圧迫)は凄い事になり易いそうなので、メモリが更に一桁カイゼン(量が一桁増え、値段が一桁下がる)したころに主流になるんじゃないかと個人的には思っています。
このへん、GCが高価だと呼ばれた時代が十数年前まで有ったことを思えば、「ハードの進歩によって当然化していく高級技術」の次の弾だということなのだろうと思います。
>キューバッファの読み取り頻度を落とすなり、時差を設けてやればいくらでも送信を遅延させることができる
コーディングの観点からいえば、上記のような高級なコーディングのしかたを前提としてる場合は、キューを挟んで遅延させるか否かの違いもまた隠蔽しやすくなりますね。
大改修なんかせず、ほんの一箇所キーワードだかなんだかを足すだけでOK、みたいな。
＃ていうか現状でも例えばJavaScriptのsetTimeout高階関数なんかがソレっぽいですね。＃呼びたい関数の呼び出しをsetTimeout呼び出しでちょっとラップするだけで＃その呼び出しを「後回し」にできる。＃泥縄ですがイベント処理の前後関係がゴチャゴチャになったときの回避策としてとても楽です。＃むかしこんな便利な関数が無かった時代のコーディングは非常に面倒だった…
ひとことで要約すると「Lispさんありがとう」ってことで。上記のテクはどれもLispが数十年前から研究してくれてた成果ばかりなんだよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
凄い時代になったものだ (スコア:0)
CGIによるWBメールが生まれたころには、送信ボタンを押してから画面の更新が完了するまでに数秒間が経過してしまい、それから操作を行ったとしても中止操作が間にうものではありませんでした。いまでは、中止ボタンを押すのが間に合ってしまうのですね。WEBブラウザの動作もずいぶん早くなったのだと驚かされます。
Re: (スコア:0, おもしろおかしい)
でけぇ釣り針だな
Re: (スコア:2, 興味深い)
荒しは不当でしょ。
昔は（今でも？）Webメールのシステム構築の仕方によって異なっていたものをたった一つの要素（ブラウザの描画速度の向上）を要因として向上した、なんてでかい釣り針以外の何者でもないでしょ。しかも実際は仕組みにあんま関係ないし。
cgi内からsendmail(qmail)呼び出ししてからhtml送信する様なごく単純なシステムからフロントエンドhttpサーバー複数持ち＆バックエンドに複数のsmtpサーバー持ってキューバッファにある送信待ちメールを定量的に送信するシステムまで様々。
# ちょっと色物ではローカルのメーラと同じ事（設定されたsmtpサーバに
#
Re:凄い時代になったものだ (スコア:0)
>最近の主流
主流ではなくまだ「次世代」と呼ぶべきでしょうけど、
「継続ベースのWebアプリ/Webサーバ」だと
mod_hogeやServletどころか
ひとつの「関数」の途中で処理を一時中断というか待たせることが出来て、
しかもそのあいだにユーザへのレスポンスを返すことが出来たりします。
デスクトップアプリでいう「ダイアログ」のような振る舞いを、
凝ったコーディングをせずに(Request/Responseペアやイベント駆動を意識する必要なく)、
やれてしまいます。
VBでDialogを出したり、JavaScでAlertを出したりするとき、
特にデフォルトのお仕着せダイアログを出すだけなら、
result = hogeDialog.show();
とか1行を「呼び出す」だけで済みます。(呼び出されるコールバックを意識せずに済む)
こういうコーディングがWebアプリでも出来るってこと。
で、これだと、私も良くは知りませんが多分、
いわゆる起動オーバーヘッドは減ると思います。
なんせ立ち上げっぱなしなのですから。
ただし引き換えというか当然の結果として、
その関数を立ちあげたまま保留しとくためのコスト(主にメモリ圧迫)は凄い事になり易いそうなので、
メモリが更に一桁カイゼン(量が一桁増え、値段が一桁下がる)したころに
主流になるんじゃないかと個人的には思っています。
このへん、GCが高価だと呼ばれた時代が十数年前まで有ったことを思えば、「ハードの進歩によって当然化していく高級技術」の次の弾だということなのだろうと思います。
>キューバッファの読み取り頻度を落とすなり、時差を設けてやればいくらでも送信を遅延させることができる
コーディングの観点からいえば、
上記のような高級なコーディングのしかたを前提としてる場合は、
キューを挟んで遅延させるか否かの違いもまた隠蔽しやすくなりますね。
大改修なんかせず、ほんの一箇所キーワードだかなんだかを足すだけでOK、みたいな。
＃ていうか現状でも例えばJavaScriptのsetTimeout高階関数なんかがソレっぽいですね。
＃呼びたい関数の呼び出しをsetTimeout呼び出しでちょっとラップするだけで
＃その呼び出しを「後回し」にできる。
＃泥縄ですがイベント処理の前後関係がゴチャゴチャになったときの回避策としてとても楽です。
＃むかしこんな便利な関数が無かった時代のコーディングは非常に面倒だった…
ひとことで要約すると「Lispさんありがとう」ってことで。
上記のテクはどれもLispが数十年前から研究してくれてた成果ばかりなんだよね。