以上、よろしくお願いいたします。sidebar以上、よろしくお願いいたします。(バグか?)自分でも(てか、自分だけ?)alpha5を試しているのだが、クライアントがどうも「メモリ喰らい」の感がある。一応、クライアント側はnow/friends/mentiosのそれぞれのメッセージを最大200件づつまで持てるようになっていて、余計なメモリ確保をしないようにしているつもりなのだが、動作途中でつくられるオブジェクトの解放がされないのか、どんどんメモリを消費しているようだ。firefoxでしかためしてないけど。JavaScriptだから動的なメモリ確保は言語任せだし、オブジェクトの参照がなくなればメモリは解放されるはずではあるのだが、どうもそうなってはいないみたい。どこかで参照が残り続けてるのかもしれない。通常のwebページであれば、継続的に表示されつづけることはないので、多少メモリリークしていてもブラウザを閉じちゃえば完全に解放される。そのページ(webアプリ)を開き続け、さらにそのページ内で動的にいろいろ動作するので、メモリリークは深刻な問題だ。手っ取り早い解決方法は、重くなりはじめるポイントを見つけて、そのタイミングでページをリロードしてしまえばいいのだけど、現在のクライアント実装だとリロードするとそれまで溜め込んでいたメッセージ情報も解放されてしまうので、ユーザインタフェース的にはダメだろう。解決策として、クライアントの溜め込んだメッセージをサーバ側で保存して、リロード時にそれをクライアントに渡す。いう方法を考えたのだが、twitter自身をメッセージのストレージとして使う的な目標もあるので、この方法は本末転倒。なんかうまい方法を考えないとなぁー。alpha5まだアルファ版ですよ。機能が決定できないのでいつまでたってもアルファ版です。どこぞの「永遠のベータバージョン」よりひどい状況だなw。クライアント、サーバとも書き直してみた。クライアントのほうはalpha2~4まで、timelineはIFRAMEを使って子ページで実行したいたけど、親子間でデータの受け渡しが面倒になってきたので、YUIのタブ機能を使って1つに納めることにした。ファイルを分離すればコードの見通しがよくなるだろう、という単純な発想からIFRAMEつかってみたのだけど、親子間でいろんなデータの受け渡しをするようになってくると、逆に分離されていることの煩わしさが気になり出して、今回、クライアンのト書き直しでJavaScriptのコードが減ったので、まとめてしまうことにした。対応ってか、完全依存。APIを発行するので、APIは完全に依存してしまった。これだとtwitter停止時に独自にメッセージ配信をおこなう。いう当初の2大目標のうちの1つが出来なくなってるのよねー、、、いや、できなくはないのだけど、サインインをどうするかを決めてないので、結局、このバージョンでは出来てないわけです。tweet側で会員登録するのでは本末転倒だし、なんか安くてうまい方法あればなー。OAuth認証されたら、「認証済みだよ」cookie設定しておいて、twitter停止時はだけそのcookie参照すればいいかな。twitter停止時だけ利用するなら、そんなに悪利用されることもないだろう。ないよな?なければいいな。(T_T)で、TLは最大200メッセージまで保持できるんだけど、現バージョンは20固定。最大TL数は内部では変数でもっているので単に手抜きで20で固定しちゃっている状態。timelineのアップデートインターバルなんかもそうなんだけど、ここらへんはクライアント側の設定画面で変更できるようにするつもり。表示や回線負荷は個人の環境に左右されるからね。変更はないんだけど、フォローしていない第3者にreplyメッセージが配信されちゃうって不具合があったので、その対策。これはtwitterのfriends_timelineと同じ動作になるように工夫した。本当にこれは工夫が必要。tweetは全twitter会員のfollowerリスト持ってるわけじゃないから、だれがだれ宛にメッセージを配信するかの判断をさせるのは結構面倒な処理だった。