Chromeでローカルファイルの読み書きの目処が立ったということで、Firefox にも同じ機能を実装してみる。Firefox の拡張からローカルファイルを操作するための API はいくつかあるが、新規に実装するということで最もナウい OS.File を使う。どれくらいナウいのか、なんと言っても完全に Promise と融合したインターフェースになっていると言うことだろう。これは今風だ。ナウいぜイマいぜ超マブいぜ。

ちなみに Presto Opera に対しては同じ機能を実装することはできない。Presto Opera 上の wasavi で file: スキームのファイルの読み書きを試そうとしても必ずエラーになる。前の記事の通り、Opera Unite がポシャらなければそれを経由して何とかなったんだけど……。

もう一つちなむと、かねてから記事にしている通りビューとモデルの分離という大きな作業も並行して行っている。そして、それが完了したバージョンから、wasavi はもはや Presto Opera 向けにはリリースしない。

* * *

実装した。

Chrome と Firefox でローカルファイルの読み書きで最も違うのは、後者はローカルファイルシステムそのものを取り扱うことができるのに対し、前者は LFO アプリケーションというラッパーを通す際にマウント位置が自由であることで実質的にローカルファイルシステムが仮想的になってしまうということだ。これはファイルシステムのルート以外をマウントした場合に違いがはっきり現れる。

実際のファイルシステム上の /home/akahuku を LFO にマウントする。このとき、wasavi を起動する。wasavi 上のカレントディレクトリは [cci]/[/cci] なので、Chrome の場合は wasavi 上で [cci]:r [/cci] したとき補完されるファイル群はホームディレクトリ直下のファイルだが、Firefox の場合はルート直下のファイルになってしまう。

LFO でどこでもマウントできるという仕様自体に何か問題があるわけではないので、これは運用でカバーすべき問題かもしれない。つまり Chrome 版 wasavi でローカルファイルを扱うための現実的な作業手順というのは、

• LFO でドライブのルートをマウントする
• wasavi の exrc で [cci]cd /path/to/home[/cci] する

ということになる。

* * *

ローカルファイルアクセスが可能になることでもう一つ影響を受けるかもしれないものがあって、それは exrc だ。ホームディレクトリに .wasavirc を置いておいたほうが楽な場合は多々あることだろう。ただし、ここでも若干問題があり、Chrome の filesystem では現在のユーザのホームディレクトリがどこかを得る手段がない（そもそも現在のユーザというものが、OS にログインしているアカウントなのか、ブラウザの同期サービスにログインしているアカウントなのか？）

これは、LFO でホームディレクトリがどこかも登録させるようにすべきだろうか？