#今朝、gauche room で斉藤さんからえんどうさんまでの発言が飛んでた。
#お、アーカイブで消えたってこと?
#久々だったけど、実は気づいてないだけだったりしたらやだなあ
#そうだとおもいます。
##「CLのラムダリスト…」の次が「それなんだけど、…」
#だから、もっと沢山か
##ここまでかな
#あ、だからこれはnoteをresumeしたからか
#今、archiveにアクセスしたら読めますよね?
#あ、もしかすると、truncateされた後で
#posが元のposを追い越しちゃったので
#rereadが起きなかった、ということかな?
#でしょうね。
#posに加えて日付も返して、それが違ってた場合も読み直すくらい？
#posの他に、current.datのgenerationという概念を設けようかなと思ってて。
#generationはcurrent.datがtruncateされる度に単調増加。
#generationを別途覚えておくのですよね？
#その場合のメリットはなんだろう？
#truncateを一日一回以上できる？
#アーカイバが一日のうちのいつ走るかわからないので日付だと面倒なのでは、という気が。
#しかしすごいっすよね。Lingr停止になるって聞いて、数時間でさらっとこんなサイト立ち上げちゃうあたり…
#高々一日一回ならuniqueになるんじゃないかと思ったけど、まさに日付の変わり目だとすると環境によっては変なことになるかなあ？
#generationでもdnsと違って、大小関係を問わなければそんなに問題ないかな
#いや、例えば日本時間の10:00amにアーカイバが走ったとして、
#あ、日付と言ってもclientはopaqueなものとして扱うつもりでした。
#9:00amにクライアントがスリープ、その時点でpos=pos1→10:00amにtruncate、pos<pos1→その後発言が増えてpos>pos1→クライアントが復帰
#むむ? でもそれならgenerationでも同じことでは?
#サーバサイドでもアーカイバは日付の変わり目に走るとは限らないですし
#ああ、ちなみにgenerationと言ってるけど、数字の値に意味があるわけじゃなくて、インクリメントしてけばuniquenessが保証されるってただそれだけの話です。
#日付なら記録しておかなくてもいい、っていうだけです
#初期値は乱数？
#え、どっちに記録?
#サーバ側で。
#毎回０から始めたらだめですよね？
#一日以上たてばいいけど
#ああ、もしかして日付ってcurrent.datのctime?
#いや、でも三日サスペンドしてたノートとかが、三日目にリブートしたサーバを相手にするとダメかな。
#いや、20090624とか
#20090624でも、その日付の途中でcurrent.datが変わっちゃうわけで、その前後を区別しないとならないのでは
#ああ、そうか
#current.datの変更に同期したidでないとだめなので日付はだめ、という点は納得。
#初期値は？
#初期値は別に何でも。uniqueでさえあればいいので0から始めても構わないんじゃないかと思うんですが困ることあるかな
#ctimeはappendした時も変わるのかな。それなら使えない
#上の三日サスペンドしたノートの例は？
#ん? その間にcurrent.datがtruncateされていればgenerationは進んでいるし(したがって要reread)、truncateされなければgenerationは同じ(したがってrelead不要)、ってことでいいんじゃないかと思うんですが
#ある時点でgeneration 0を覚えていたノートを三日サスペンドした。ちょうどresumeしたその日にサーバがわも
#リスタートした。
#ああ、generationはpersistentな情報です。
#具体的にはそういうファイルを作って数字を書いちゃう。
#やっぱりサーバ側で記録しておくんですよね
#です。
#今でもlast-postのタイムスタンプとかファイルで管理してるし、手間はそんなに増えない
#というか、generationをアップデートするのはarchiverで、参照するのはviewerなんで、何らかの通信経路が必要。ファイルでやるのが一番てっとりばやいかと。
#なるほど
#@cut-sea Comet自体は別に難しくなくて、本当に大変なのは大量のコネクションをさばくようにスケールしたり、「サービス」としてたくさんのユーザと関係を築いてゆくことだと思うので、「欲しい人は勝手にサーバ立ててね」でスケールすることを放棄し、既にLingrにあった関係をそのまま頂いたChatonは、面倒なところを全部回避しているのですよ。
#うーん。そなんですか。でも数時間でさらっとサービスが立ち上がるのはすごいなーと心から思います。
#自分的に嬉しかったのは、ずっと「思いついたらすぐ作ってみる」のにふさわしい道具が欲しいと思ってgaucheを作ってきて、それがそういう道具になっていたことを確認できたこと、かな。
#こういう現実のことをやるとやはりライブラリの存在って大きいですよね
#今どきだと、ちょっとした実験するならhttpdがライブラリになってて欲しいですね。
#chatonでは前に書いたやつをコピペしましたが
#あとmimeメッセージを組み立てるところもrfc.mimeに入れないと。
#chatonを作ったときにgaucheに取り込めそうな部分ってありました？
#こういうインタラクティブなWebサービスを書くのに使えるライブラリというか
#見てないので良くわかりませんが、普通のWebサイトとはっきり違う性質があるじゃないですか
#むずかしい。基本的に目的に特化して最短距離で書いたから、まとまって汎用的に切り出せるものってあんまりなさそう。
#細かいものでは、上記mimeメッセージのとか、ちょこちょこあると思うけど。
#ああ、一時ファイルに書き出してrenameする、っていうイディオムは本体に入れようと思った。
#当初はwith-output-to-fileとかへの機能追加を考えてたんだけど、ちょっといじってみて今ではwith-output-to-temporary-fileとか別のAPIがいいんじゃないかと思ってる。名前がこれだと長すぎるので検討中。
#確かにそれよく使ってた気がします
#それってどういうメリットがあるんでしたっけ
#少なくともunixでは、同一ファイルシステム上のrenameはアトミックなので、変更途中のものが見えたり混ざっちゃったりすることがない
#じゃあwith-safe-output-fileとか
#with-output-file-with-safe。withがうざいか
#safeだとちょっと意味が広すぎると思って。2人以上が同時に変えようとした場合は、後からrenameした方だけが残るから。
#もっともcopy-fileに既に:safeってキーワード引数あるんだけど
#上記の理由でいまいち。
#なるほど
#ただtemporaryもなんか実装に立ち入った名前で気になりますね
#atomicっていうのも考えたんだけど、2人以上の変更の衝突があるとやっぱりatomicは言い過ぎかなあとか
#temporaryに書いてrenameってunix的にはポピュラーだから、それを表す名前で必要十分な説明はできるかな、という考えはある。
#atomicか、それもいいかも。
#個人的にはtemporaryよりはなんか目的というか仕様を反映している感じがすき。
#write-to-output-file/atomic とか call-with-output-file/atomic とか
#私の好き嫌いはどうでもいいけど
#うん、今cut-seaさんに説明してて、自分でも「あれ、atomicでいいんじゃね?」という気はしてきた。
#お、よさげですね
#atomicな操作でもそれを二回やれば二回分の副作用はあるわけだし
#いいんじゃないですか
#それもそうですね。書いたものは、それが欠けずに残るか、上書きされて消えちゃうかのどっちか、という点ではまさにatomic
#そんじゃatomicで行こう。
Chaton > Archives > 2009/06/24