Summary

  • W3Cが2009年4月23日に公開したServer-Sent Eventsの作業草案は、サーバーから届く更新をページがEventSourceで受け取る仕組みを記述した。
  • 更新にはidを付けられる。接続が切れると、ブラウザーは記憶したIDをLast-Event-IDとして次の要求に載せる。空のidはその記憶を消す。

相場の数字が動かなくなる。市場全体が一斉に考え込んだ、という可能性は低い。線が切れたのだろう。しばらくして画面に新しい数字が現れると、かえって落ち着かない。さっきの数字と今の数字の間で、何枚の紙がテープから落ちたのか。画面だけを見ても分からない。

2009年4月23日のW3C作業草案は、ページがEventSourceを作り、HTTPでサーバーからイベントを受け取る方法を示した。応答の形式はtext/event-stream。ブラウザーが行を読み、まとまったブロックをイベントとしてページへ渡す。接続を開いたまま細切れの知らせを受ける仕組みだが、再接続時にどこから話を続けるかという問題も同じ文書の中心にあった。

草案の株価の例は、古い相場テープを少し連想させる。data: YHOO、data: +2、data: 10という三行のあとに空行が来る。そこで一件のイベントが完成し、ページの処理が三つの値を取り出して表示を更新する。行が一つ届くたびに画面へ投げるのではなく、空行までを一通の知らせとして扱う。この単純な区切りが、流れ続ける応答に読みやすい節を作った。

次の例では、最初の知らせにid: 1が付く。ブラウザーは「1」を覚える。次の知らせが届く前に回線が落ちたら、再接続の要求へLast-Event-ID: 1を入れる。2009年12月の最終意見募集草案にも、この再接続の設計が残った。もう一度窓口に並ぶとき、読者が「どこまで読んだか」を言える。職員に記憶を当ててもらう必要がない。

もっとも、しおりだけでは失われた紙面は戻らない。過去のイベントを保管しているサーバーなら、その番号を手掛かりに続きの候補を選べる。保存期間が過ぎていれば別の扱いが必要になる。銘柄の速報をいつまでさかのぼらせるか、取引日が替わったらどこから始めるかは、配信する側の決定だ。ブラウザーが持つのは自分が実際に受け取った位置であり、サーバーが持つのは記事の束である。

草案は、しおりを捨てる方法まで例示していた。後のイベントに値のないidフィールドが現れると、記憶されたIDは空になる。次に接続するとき、Last-Event-IDは付かない。昨日の相場のページ番号を今日の速報へ持ち込まないための、小さな仕切りだ。継続の道具には、継続をやめる手順も要る。

コロンから始まる行はコメントになり、ページへのイベントを発生させない。2015年2月3日のW3C勧告は、長く静かな接続を古いプロキシが切ってしまう場合に、こうしたコメントを時々送る案を挙げた。同じ勧告には再接続までの時間を指定するretry、再接続を終わらせるHTTP 204 No Contentもある。テープを送り続ける装置には、呼吸の合図と閉店の札の両方が必要だった。

W3Cの公開履歴には、2009年の草案群、2012年の勧告候補スナップショット、2015年の勧告が並ぶ。完成した仕組みの魅力は、大げさな記憶装置ではない。ブラウザーが一つの番号を持ち、サーバーが自分の記録と照らす。線が切れたというありふれた事故を、両者で扱える問いに変えた。

先に書いたWeb Workersの歴史では、ページの外で計算する役が主役だった。ここで動くのはサーバーから届く知らせの列だ。一方は重い計算でボタンを黙らせないための分業、もう一方は途切れた知らせをどこから読み直すかという分業である。相場テープは数字ばかり並ぶが、いちばん大事なのは、切れた場所の印だった。