#あら、Safari はだめかな。document.forms とかは環境依存かも。
#getElementByIdって標準? ならそっちの方が確実かも。
#getElementById はたしか DOM のメソッドだから標準のはず。
##javascript:(function(t){t.value=t.value.replace(/<<gaucheref:(.*)>>/,"http://practical-scheme.net/gauche/man/?l=jp&p=$1")})(document.getElementById("post-text")) #<<gaucheref:iota>>
#だめです。orz
#あれ、書き込み欄でエンターを押す前に、JavaScript を実行しています？
#<<gaucheref:iota>>
#アドレスバーに入力して評価させるんですよね?
#それともブックマークしなきゃだめなのかなあ
#はい。えっと、まず、Text: に <<gaucheref:hoge>> と書いて、そのまま送信しないでおいて、
##それから、アドレスバーに javascript をいれて、ENTER。
#あ、変わった
#あ、できた。
#そういう手順なのか
#手でやるのはちょっとややこしい。
#一度評価させておくとtextareaを監視してくれるのかと妄想した
#あー、そこまで賢くないです。単に replace で置換しているだけ。
#りょうかいしました
#でも監視するようにもできるかな。onchange を監視するのも手かも。
#addEventListnerとかすればできるのかなあ
#Chaton自身もkeypressかなんかを監視してるのでぶつかると厄介かも
#ですね。
#Bookmarkに入れれば、[textboxに入力]->[Bookmarksから選択] の2ステップなのでそんなに面倒ではないですね
##おっと、全角空白がURLの区切りとして認識されないぜ
##おお。いちばんのり。
##220.156.x.xさん、どうもやっぱりcidの引き回しがうまくいってないみたいです。
#Chaton側の問題かも。何をやろうとしているか教えていただければこっちもいじれるかもしれません。
#長い猫ネタ。えんどう家の猫なら対抗できる
#今の状況だと、220.156.x.xからのアクセスの度に新しいユーザの入室とみなされて、ユーザ数変動のイベントがブロードキャストされるのです。
#私のことでしたか、ずっとROMっていたので気付きませんでした
#いちおう、認識できないcidでリクエストが来た場合、新しいcidをこちらで割り当てて返すようにしているんですが、どうもそうやって割り当てたcidが次に来た場合にまた新しく割り当てちゃってるので、chaton-viewerのバグかも。
#Safari 3.2.1を使用してただ見ているだけなのですが、誰かが発言すると１つの発言が何度も表示される状態でした。
#あれれ、ということはこっちのjavascriptがおかしいんですね。
#一応ページのリロードをしたら直ったみたいです。
#Ajaxインスタンスがいくつも同時に走っちゃってるのかなあ。
#確かに今はアクセスが正常になっています。
#はじめから何度も表示されることはなかったです。いつの間にか何度も表示される用になってました。
#何かのタイミングでおかしくなるようですね。
#むむ、Windows版は3.2.2からしかダウンロードできないみたいだなあ
#watchdog timerが悪さをしているのかもしれない。
#あー、またなりました
#確かに重複して接続しています。
#スクリーンショット送った方がいいですか？
#さっき右下の表示が一度Connecting...になったのでそれが原因かもしれないですね
#Ajax接続が重複していれば発言が重複して挿入されるので、スクリーンショットは無くても大丈夫です。
#とりあえず別のブラウザから見るようにします
#すみません。
#てっきり誰かがプログラムで発言をモニタしようとしてるのかなとか思ってました。
#同一IPから複数接続に来てたので。
#とりあえずFirefoxから接続し直しました
#待てよ、もしかして。モバイル環境とか、ネット接続が不安定ということはありますか?
#あ、HTTP ヘッダみれば一応ブラウザの種類がわかるから（偽装してなければ）、動作の傾向がつかめるかもしれませんね。
#ですね。今ヘッダはログってないや。
#あーまたなった
#多分ルーターが不安定になってるかもしれません。安物なので…
#これは複数接続防止の何かをこっちのjavascriptに入れるべきですね。
#自動的に再接続されるとなるっぽいです。（またConnecting...）ってでたので
#Firefoxでつなぎ直してから8分くらいでConnecting...が出ましたか?
#たぶん、それくらいだと思います
#もしそうならwatchdog timerだ。
#あ、8分じゃないです。
#kazuya_a
#
とりあえずFirefoxから接続し直しました
#この発言から少したったくらいです
#ああ、2分くらいですね。じゃあtimerじゃないな。
#ルーターが不安定なせいかもしれないのでルーター再起動して来てみます。
#お手数かけてもうしわけないです。こっちでも対応を考慮中。
#再起動してきました。
#むむ。今度は別のIPから4重に接続が…
#また、なってました
#ページをリロードするとすぐつながるのに、「connection lost」->「Connecting..」だと再接続までかなり時間かかってます。
#そこは5秒から15秒程度のディレイをわざと入れてあります。
#なるほど
#原因は不明ですが、確かにそちらからのcomet接続を待たせている間に、新たなcomet接続要求が来ます。request uri中のキャッシュ避けタイムスタンプが違うので、
#今別マシンから接続しているのですが、また発生してしまいました。
#javascriptレベルで再送がかかっている(fetchContentが重複して呼ばれている)のは確かなんですが、なぜそうなるのかはまだわかりません。
##Apple Script,Java,Perl,Python,Tcl,Ruby
#GaucheでGrawl binding書こうと思ったらCarbon使った方がいいのかな?
#c-wrapperがObject-Cブリッジできるから、c-wrapperからCocoa呼んじゃえば?
#Objective-C
#Object-Cって何だ(笑)
#ああわかったかも＞多重接続。Firefoxでは、comet接続が切れた時になぜかonSuccessハンドラがまず起動され、それからonExceptionハンドラが起動される
#Safari4は接続切れを検出できないのでわからないけど、Safari3がFirefoxと同じだとしたら説明がつく
#「本当に」接続が切れた場合、onSuccessハンドラのjsonにはnullが渡ってるので、この処理は今までどこかで中断されていて気づかなかった。でも経路不安定による接続切れの場合、何らかのデータが入っていてonSuccessハンドラからのcomet再リクエストまでいっちゃうのかもしれない。そうなるとonExceptionハンドラからの再接続と、重複してcometリクエストが張られることになる。
#しかしこの仮説が正しいとすると、どうやって切断を検出すればよいのだろう
#Heart Beat?
##Grawl for Windowsですと
#今でも5分に一回はやりとりしてるんで、それが受け取られない＝切断、とみなすのはwatchdog でサポートしている。
#でもそれだと切断検出に数分待たないとならない。
#切断検出を早めるためにheartbeatのペースを短くしたら、ほとんどpollingと同じになってcomet使ってる意味がなくなる。
#確かに
#難しいところですね
#Lingr mo
#かなり時間が経ってから切断されたような気がする
#firewallとかproxyのレベルでタイムアウトして切断されるケースもあるから、いずれにせよonSuccessハンドラでもって本当にサーバから返事があったのかどうかのチェックは必要だなあ。
##こっちのがよいかも
##コマンドラインから使える
#nobsun来た?
#ああわかった。Firefoxで切断時にonExceptionが上がっていたのはAjaxオブジェクトが上げていたんじゃなくて、onSuccessハンドラが空のjsonパケットを処理しようとして失敗して例外をあげてたんだ。なるほどそれなら説明がつく。
#onSuccessの中でレスポンスを調べるのが正しい方法ということだな。
#重複リクエスト対策を入れてみた。さてどうなるか。
#テスト
#こんどは再接続されても大丈夫っぽいです
#先ほど、(多分)kazuya_aさんの方から重複リクエストが来ていました。しばらく"Connecting..."のままだったんじゃないかと思います。
#はい、Connection Lost->Connecting...を数回繰り返していました。
#実はその間、最初に張ったcometコネクションは生きているので、そっちのcometコネクションに正常なリプライが渡った時点で正常な状態に戻ると思います。
#本来は重複検出した時点で正常状態に戻すサイクルに入るともっと良いのですが、とりあえずはこれで異常状態のままになることはないかなと。
#なるほど
#私の方でConnection Lostが起きるのはpolipoというProxyサーバーソフトを経由させているかもしれません。
#それはありえますね。cometで待っている間は通信が発生しないので、proxyにとってはサーバが死んでいるのと見分けがつかないですから。
#proxyサーバーの設定をいじったので今度は重複リクエストを送るようにならなくなったと思います。
#Cometリクエスト受け取った後、ヘッダだけでも先に送り返した方がいいのかなぁ。
#Content-Lengthの値が検討つかないんじゃないですか?
#見当
#到着
#うぃ
##これをダウンロードして読んでみる。
#ぼくも以前 polipo をつかっていました。Lingr の時はとくに問題なかった気がしますが、実は重複してつないでいたのかも。
#ヘッダを先に返す場合、200 を返したあとで、処理の途中でサーバがこけると、おかしなことになりませんかね。
#Lingrはそのへんしっかりやってたんじゃないでしょうか。
#いやでも、comet じゃなくても大きなファイルのダウンロードの途中で回線が切れたりすることは考えられるから、いいのかな。
#サーバがこける問題は、エラーをどのレイヤで出すかってことになるので、httpのレベルでは200を返してアプリケーションレイヤでエラーにするってのもありでしょう。
#proxyのタイムアウト問題は、クライアントごとに状況をモニタしてadaptiveにheartbeat rateを変えればいいんじゃないかと思う。ちゃんとしたサービスにするにはそういう細かいところの造り込みが大変だねえ。
#まあ再現方法がわかったのはありがたい。
#$ growlnotify -t 'title' -m 'ほげ'
#おお。とりあえず通知はこれでいいや。
#$ growlnotify --image ~/Downloads/chaton-room-gauche.gif -t 'Chaton Gauche' -m 'うぃっす'
#アイコンもおけー
#クライアントはchaton.jsと同じ事をやれば良いのでしょうか
#いまAPIつくってるからまってて
#了解っす
##ローカルで使ってるMac OS XのDictionalアプリよりもレスポンスいいかも
#軽いねぇ。
#しかし、「健康」って入力した時、一覧に「健康上/けんこううえ」ってのが出ちゃうのはどうなの(笑)
#POP 辞書のところが作ってるんですね。
#MONO でできてるのか。
#ほー
#MONOで作った実用サービスって初めて見た
Gauche > Archives > 2009/05/13