とは言ってみたものの、本当に大丈夫なんだろうか。

とりあえず wasavi のバックエンドが localStorage に保存するデータのキーを列挙してみよう。

• version: 現在インストールされている wasavi のバージョン文字列
• targets, exrc, shortcut, shortcutCode, fontFamily, fstab, quickActivation, qaBlacklist, logMode, sounds, soundVolume: オプションページから編集することのできる項目群
• memo-*: body 要素に対して wasavi を起動した場合その内容は localStorage に対して読み書きされる。これを Memorandum と呼んでいて、localStorage 上の memo-* キーは各 URL ごとの Memorandum の内容を保持している。* の部分は URL の SHA-1 値
• filesystem.*.tokens: 各クラウドストレージに接続した際のクレデンシャル
• wasavi_lineinput_histories: 行入力モードで入力された値の履歴
• wasavi_registers: レジスタの内容

こうしてみるとキャメルケースだったり [cci]-[/cci] で繋いでいたり [cci].[/cci] で繋いでいたり [cci]_[/cci] で繋いでいたりとてもアレだがまあそれはそれとして。ユーザーをスイッチした時、リセットされるべきものと触るべきでないものを明確にしたい。大体の区別は前者は Chrome にログインするアカウントに属する情報、後者はローカルマシンに属する情報ということだ。

まず version は明らかにローカルマシンに属する。これはいい。したがって同期されるべきではなく、かつユーザーがスイッチされたとしても変更されるべきでない。

次にオプションページの項目は当然ながら同期される対象であり、ユーザーがスイッチされた場合は新しいユーザが所持するデータのものに差し替えられるべきである。

ここまでは簡単だ。これ以降が難しい。

Memorandum はまだその仕様自体が固まっていない。とりあえず version と同様の扱いにしておこう。

クレデンシャル。クレデンシャルの情報はクリティカルであり同期で使いまわすのは怖い。一方でユーザースイッチの場合はどうなんだろう。クラウドストレージに対して受けた認証は Chrome のアカウントでもローカルマシンでもなく各ストレージのアカウントだ。ということは Chrome のアカウントがスイッチされたとしても触らないほうが良いのだろうか。なんとも判断できない。

行入力履歴とレジスタはまた異なる疑問点がある。使い勝手で考えると、これらが Chrome のデバイス間で共有されるのはまあまあ便利だと思う。しかしこれらの情報ってかなり頻繁に更新されるのだ。デバイス A で wasavi を起動し履歴とレジスタの内容を更新する。それを同期に載せる。デバイス B でも wasavi を起動する。同期イベントがやってくる。ローカルで更新した内容が上書きされる。そんな感じで不整合が簡単に起こりうる気がする。ということは実装の都合上同期しないほうがいいのかもしれない。ユーザースイッチの場合はどうか。これもなんとも判断できない。

…ということなのだが、いまいち確固たる理由付けによる区分けができない。