wasavi は Chrome、Opera、Firefox にそれぞれリリースしている。その中で、Chrome と Firefox はアクティブユーザー数を知ることができるのだけど、それぞれ 300 人台とか、100 人台とかである。これは、他のエクステンションを適当に眺めてみる分には、かなりつつましい数字だ。
これをたとえば万のオーダーにするには、やはりどこかのサイトで紹介されて爆発的に知れ渡る的なイベントが必要なんだろう。そして、それが起こるのを待つと言うよりはむしろ、こちらからいろいろな IT 系ニュースサイトに「wasavi を紹介してくださいお願いします」といった営業活動をしなくてはならないんだろうと思う。
しかしめんどくさそーなので別にやらないのであった。そもそもよく考えたら、ユーザー数が増えても別にメリットないじゃん。
Selenium に実行させるテストの総数が 666 になった（アサーションの総数は 2700 くらい）。
全コードの 66% が wasavi、33% がテストコードである。うーん半々くらいに持ってきたいところだが……。
クリップボードを介した貼り付けについて、Clipboard API をちょっと使用してみた。
貼り付けなので、ctrl+v か、shift+insert を押した場合に document に対して paste イベントが発生する。イベントハンドラの中で e.clipboardData.getData(‘text/plain’) とかすると貼り付けようとする文字列が得られる。その文字列を vi のコンテキストに従って適切に貼り付ける。また、e.preventDefault() してデフォルトのアクションは取り消しておく。
ただし、ctrl+v は挿入モードや行入力モードでのエスケープシーケンスの入力開始文字とかぶっている。そこで、貼り付けイベントを認識するのは shift+insert だけにした。この特別扱いを行うと、そのキーを再マップできなくなってしまうので、なおのこと ctrl+v は明け渡すことはできないのだ。
これにより、Presto Opera で wasavi を動かしている場合でも、限定的にクリップボードを使用することができるようになった。限定的というのはまず、書き込みはやはりできないということだ。また、コマンドモードで shift+insert した場合でもとりあえずクリップボードからの貼り付けを行うようにしたのだが、内部的には [cci]”*p[/cci] を実行するだけであり、エクステンション側でクリップボードの読み書きが自由にできない Presto Opera では動かない。
ついでと言ってはなんだけど、キーボード入力のハンドラで入れ子になっているコールバック関数を外に出した。つまりキー入力ごとに関数の評価を行なっていただろう箇所を取り除いたのだけど、なんか目に見えて入力のスピードが速くなった？ えっそんなに差があるの。
javascript 製の vi というものをググってみると、以前から JS Vim なるものがひっかかるのだが、概要に述べられているリンクが 404 だったり、ドキュメントの類が一切なかったりで、何者がどういう意図で作ったものなのかよくわからず、気になっていた。
どうも ここ が現時点で有効なサイトのようだ。ページ上に実装済みの機能が示されているが、それほど多くはない。また、ex コマンドのたぐいはまだ実装されていない。
作った人の位置づけとしては vi clone ということらしいのだが、個人的な感覚で言えば、ex コマンド群を実装せずに vi clone と名乗るのは良くない。それはせいぜい「なんちゃって vi clone 見習い心得」くらいのものだ。
それはそれとして、sourceforge 上のソースは 2.0 だが、件のページでは 3.0 と地道に更新されているようなので、頑張ってほしいと思った。
リリースした。Google Drive への対応と ex コマンド入力時の各種補完がメインになっている。
ファイルをアップロードするために Google Drive が提供する API を呼び出す際、Exponential Backoff なる方式にするといいよ、と google 先生は言う。
なにやら難しい専門用語である。exponential とは指数のことだ。しかし内容はわりと明快で、ファイルをアップロードした際に何らかのエラーが発生した場合のリトライの待機時間をべき乗則にするといいんじゃね？ ということである。
wasavi ではこれは実装していない。書き込みが失敗したらエラーだよ♪ と表示されてそれだけだ。ファイルへの書き込みはユーザーが明示的に指定するので、エラーが発生したらユーザーが再度指定すればいいのである（このインターフェースには異論はあるかもしれない）。
ex コマンド filesystem を実装した。最短は files。最初の引数がコマンドであり、以下の種類がある:
:filesystem default:filesystem default gdrive
:filesystem status
*** available file systems ***
* dropbox /
gdrive /foo/
また、ex コマンド pwd、chdir、cd も実装した。機能は読んで字の通り。
dropbox、google drive と、wasavi から複数のオンラインストレージを読み書きできるようになる。その場合、ストレージの種別を区別させる必要が出てくる。そのため、wasavi 上でのファイルパスは接頭辞を付けることができる。[cci]dropbox:/path/to/file[/cci] とか [cci]gdrive:/path/to/file[/cci] というような感じだ。
このようにファイルパスを操作するとき、ストレージ・プリフィクスは省略可能である。ということは省略したときはよきに計らってくれるデフォルト値が必要ということであり、すでに内部ではそれを持っている。ただし今のところ dropbox 固定であり、変更する手段がない。どういう変更手段を設けるべきか？
ex コマンドを新設し、[cci]:filesystem default dropbox[/cci] などと指定できるようにするか？ あるいは、そうではなく、単にオプションを増やして、[cci]:set filesystem=dropbox[/cci] とさせるか。
うーん、後者が自然かな。ただし一方で、デフォルトのファイルシステムの指定、のようなメタな設定は他に
のような機能はいずれ必要になる。そうすると、「ファイルシステムのメタデータを管理する ex コマンド」に一本化したほうが長い目で見ればいいのか？
省略可能といえば、パス自体も常に絶対パスで指定しなければならないわけではない。つまり仮想的なカレントディレクトリもまた内部に持っておき、相対パスが入力されたらカレントディレクトリと結合する必要がある。というわけで、カレントディレクトリも内部で持っているのだが、これもまた wasavi 上から変更する手段がまだない。どうするか？
vim であれば、vim 上のカレントディレクトリを参照するには [cci]:pwd[/cci]、変更するには [cci]:chdir path[/cci] である。
こちらは、素直に ex コマンド新設コースかもしれない。pwd とか cd コマンドがあまりにもポピュラーすぎてそこから一線を画す理由がない。[cci]:set cwd=/[/cci] なんてなんだか奇妙だ。特に、相対パスでカレントディレクトリを変更する場合の [cci]:set cwd=../foo[/cci] のようなものは実際の動作とも食い違う（cwd が代入した値そのものになるわけではない）ので奇妙以上におかしい。
このうち最も強い権限を持つ drive スコープはほんとうに必要な場合のみ使ってね！ とドキュメントにも明示してあるのだが、どうも downloadUrl からの読み込みは drive スコープじゃないと行えないような。drive.file だと 404 が帰ってくる。これは……バグじゃないのかな。というわけで drive スコープを使わざるを得ない。そんなような問いと答えが stackoverflow にもあった。
残るのはファイルの書き込み。
Google Drive 上の、あるファイルへのパスが与えられたときそれを読み込む手順は以下のとおりとした:
つまり 1 つのファイルを読み込むのに 3 回のリクエストが必要になる……それにしてもイケてないなー！ もっとうまい方法はないのかしら。
あと、ひとつ気になる点がある。あるファイルのメタデータ内に、その親ファイルの ID が格納されているのだが、名前が parents で、型は配列なのである。あるファイルが複数の親を持つことができる？ どうやって？
そんなわけで、OAuth 2.0 で認証したりする Google Drive 対応部を書いている。だいたいこことここを見ればすべきことは書いてある。
ところで API のリファレンスを眺めてみると、なんか任意のファイルへアクセスするのにパス形式の文字列を使用する機能がないような？ つまり、My Drive -> folder A -> folder B -> folder C -> foo.txt みたいな位置にあるファイルを読み書きするためには、dropbox の API であれば
GET /1/files/dropbox/folder_a/folder_b/folder_c/foo.txt
みたいなリクエストを素直に投げればいいのだが、Google Drive だとルートフォルダから 1 階層ごとに
GET /drive/v2/files/root/children/
みたいなリクエストを投げて、フォルダの中身のメタデータを見て掘り進んでいくようなことをしなければいけない。当然、パス階層が深ければその分リクエストの回数も多くなる。
えー……？ 天下の Google 様がそんなアホみたいな仕様にしてるなんて嘘でしょ？ なんか方法があるんでしょ？ と思ったけど特にないようだ。
どういうことなの。なにか見落としてるんだろうか。
＊ ＊ ＊
Files:list において、q パラメータに対して title=’folder A’ OR title=’folder B’ OR title=’folder C’ OR title=’foo.txt’ みたいな物を与えて、帰ってきたデータを元にルートから目的のファイルまでのパスを自前で構築し、目的のファイルの ID を特定すれば、とりあえず読む分においては、リクエスト回数は常にパス情報の取得 + 読み込みの 2 回で済むことに気がついた。
なんかイケてないなー。