issue を少し消化する。その中に、ローカルファイルシステムのサポートというものがあり、ちょっと考えている。ちなみに、この issue を書いた人は Chrome ユーザーだ。

いうまでもなく、Chrome の extension はローカルファイルシステムにアクセスすることはできない。issue の中でこれは使えるのではないか？　という API がいくつか挙げられているのだが:

• https://developer.chrome.com/apps/fileSystem: これは、いわゆる Chrome apps 向けの API だ。Chrome apps は extension と違い、よりローカルのリソースに近い層にアクセスできる API を使用できる。しかし extension からこの API を使うことはできない
• http://www.html5rocks.com/en/features/file_access: これはローカルではあるが、ただし「サンドボックス」なファイルシステムを操作する API だ。従って既存のファイルを直接いじったりはできない

というわけで、残念ながらすぐに使えるというものはない。

現実的な妥協案としては、wasavi のうち http://wasavi.appsweets.net/ 上での動作モードを分離する、つまり extension としての wasavi、apps としての wasavi を独立してリリースするというものが考えられる。そうすれば apps モードはローカルファイルシステムにアクセスできて、よりローカルなアプリケーションっぽくなる。

この案の弱点としては、

• 2 つのリリースを考えなければならないのが開発側として面倒
• 各ページの wasavi はバックグラウンドを通して各種ヒストリやレジスタの内容や exrc その他を共有している。リリースが別になると、その繋がりから抜けることになる。特にレジスタと exrc が別になるのはすごく使い勝手が悪そうだ

もう少し別の角度から何か出てこないだろうか。もしも apps をアプリケーションではなく、ライブラリ的に使うことができればいいのだが。つまりエクステンションから接続を受け、ローカルファイルシステムの読み書きを代行する中間層として動作してくれればいいのである。そんなことが可能だろうか。

まあたぶん、こんな感じで誰でも思いつきそーな使い方は当然できないんだろうけど、一応それを確かめるためにちょっと試してみよう。

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

とりあえず 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 を起動する。同期イベントがやってくる。ローカルで更新した内容が上書きされる。そんな感じで不整合が簡単に起こりうる気がする。ということは実装の都合上同期しないほうがいいのかもしれない。ユーザースイッチの場合はどうか。これもなんとも判断できない。

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

よくリファレンスを読んでみたところ Identify API に getProfileUserInfo() と onSignInChanged イベントがあり、もちろん前者は Chrome にログインしているユーザーの情報を得るために使い、後者はユーザーがスイッチされる時に発生するようだ。

よかったよかった。これを使えば大丈夫。

とりあえず Chrome の場合のみ、[cci]chrome.storage.sync[/cci] を通して同期された設定を参照するようにした。Presto Opera、Firefox では設定は同期されない。また Blink Opera では前述の API 自体は使えるのだが、今のところ同期しないので実質的に現状と変わらない。

ところで組んでいて気がついたのだけれど。

この同期されるデータというのが何に属しているのか。もちろん Chrome に入力する Google アカウントだ。一方で Chrome には任意のタイミングでこのアカウントをログアウトしたり、別のアカウントにスイッチするようなインターフェースが用意されている。

ということは、エクステンションからアカウントに属するストレージを参照できる以上、現在のアカウントのある程度の情報やアカウントがスイッチされたというイベントも受け取れることができないと辻褄が合わなくなる。

しかし探してみてもそういうものが見つからない。[cci]chrome.storage.onChanged.addListener[/cci] で内容の変化に対するイベントをリスンすることができるが、例えばアカウントをスイッチした時に何かイベントが発生するということはないようだ。現在のログイン状態を知ることができればまあまあなんとかできるかもしれないが、そういう API もない感じ。いっそ [cci]chrome://sync[/cci] をスクレイピングとか…？　いやまさか。

これ、Wasavi に限らず storage API を使っているエクステンションに共通する問題だと思うんだけど。つまり Chrome にログインしたあと、各エクステンションのバックグラウンドをリロードするか、あるいは単に Chrome 全体を再起動しないと辻褄が合わなくなると思うんだけど。

しかし google 様がそんな仕様にするのだろうか。何か勘違いしているのかもしれない。もう少し調べてみよう。