デバイスドライバ/FUSEのrestfs/SITEINFOの役割比較

これまで、物理的なコンピュータの上でプログラムを動かそうとするときに必要な、ハードウェアの制御、プロセスの管理などなど面倒なことをやってくれるソフトウェアのことをオペレーティングシステムと呼んでいました。

最近はいままでコンピュータの上でやっていたような作業、エクセルのシートを作るだとか、パワーポイントで資料を作るだとか、ファイルを保存しておくとか、そういった作業が全部ブラウザの向こう側にあるウェブ上のアプリケーションだけでできるようになってきています。

手元のコンピュータで動いていたアプリケーションのかわりに、ブラウザの向こう側にあるウェブ上のアプリケーションを使うようになってきた結果ウェブがOSのように感じられるようになったことを指してWeb Operating Systemと呼ぶこともあります。(Web operating system - Wikipedia, the free encyclopediaによればもともとは、あるプロジェクトの固有名詞だそうです)

アプリケーションとデータの操作

昔、コンピュータがインターネットに繋がっていなかったころと、インターネットに繋がっていないコンピュータを使ったりしなくなった今とでは、コンピュータの使い方がまったく違っています。昔はコンピュータを使って、新しくデータをつくってそれをコンピュータに繋がっているディスクに書き込んだり、ディスクに入っているデータを読み込んで書き換えたりするのが主な使い方でした。

今はそれに対して、ブラウザを使ってインターネット上にあるデータを読み込んできて、その内容をに応じてまたインターネット上にデータを書き込んだりするのが一般的な使い方です。コンピュータに繋がっているディスクのデータを書き換えたりすることは少なくなりました。

もしWebがOSになるのだとしたら、そのOSに繋がっているストレージはやっぱりWeb上にあって、そうしたらそのストレージを操作するためのデバイスドライバは何？というところから、FUSEと、SITEINFOを使ったAutoPagerize/LDRizeについて考えてみました。

デバイスドライバとFUSE

Webとデバイスドライバという単語の組み合わせから真っ先に思いつくのは、いろんなものをファイルシステムとしてマウントすることができるFUSEです。以前にFUSEを使ってはてなブックマークから POOKMARK Airlines へ乗り換える方法 - bits and bytesとしてソーシャルブックマークサービスをマウントして、Web上のサービスにあるブックマークを他のサービスへコピーするはなしを書いたりしています。

ほかにもRESTなWebサービスをマウントするRESTファイルシステム、FUSEで作ってみた:TKMR.blog.showでは、RESTのAPIを持つWeb上のサービスをファイルシステムとしてマウントすることができます。

まずこのRESTのAPIを持つウェブ上のサービスをマウントするRESTfsの構造と、ほんものの物理デバイスを管理するファイルシステムのドライバの構造を比較してみました。

物理デバイス

まず物理デバイスを管理するドライバは(ぜんぜん詳しくありませんがWindowsの場合たぶんこんなです)、NTFSやext3といったファイルシステムを管理するファイルシステムドライバ(FSDと略します)、と呼ばれる部分と、そのファイルシステムに含まれるデータを実際にディスクに書き込むためのコントローラを操作するデバイスドライバとに分かれています。

現在のOSがストレージからファイルを操作するときにはopen, read, write, closeといったインターフェイスが使われています。このインターフェイスは、ファイルの操作をだけでなく、通信用のソケットやデバイスドライバの操作にも使われています。歴史的なことはわかりませんが、このインターフェイスがコンピュータ上で行いたかった様々な操作をうまく抽象化できたので結果として今まで生き残り、今でも標準的なインターフェイスとして利用されているのではないでしようか。コンピュータ上でよく行う操作をうまく抽象化したものがopen, read, write, closeのインターフェイスだと考えることができます。

どんなファイルシステムであってもOSからはすべて同じインターフェイス(open, read, write, close)で操作できるようにするための抽象化層がFSDです。FSDはファイルシステムごとに異なるディクトリツリーの管理方法や、ファイルの中身のデータが物理デバイス上のどこに書かれているかといった情報を管理しています。OSからファイルの読み取り要求があったときには、要求されたファイルが物理デバイス上のどこにあるかを調べてその位置を読みこむために(正しいかどうかかなり怪しいですが)、Linuxであればioctl, WindowsであればIoCallDriverというインターフェイスを介してハードウェアデバイスを管理しているデバイスドライバを呼び出します。

デバイスドライバは、物理デバイスがなんであれFSDからはすべて同じインターフェイス(ioctl, IoCallDriver)で読み書きできるようにするための抽象化層です。デバイスドライバはFSDから呼び出されると、渡されたパラメータに応じて物理デバイスの特定の位置を読みこみます。そのためには物理デバイスごとに異なるアドレスにマッピングされているコントロール用のレジスタに、物理デバイスごとに異なるコマンドを書き込む必要があるので、物理デバイスごとに異なっているその値をデバイスドライバの中に持っています。

この二つの抽象化層(FSDとデバイスドライバ)をはさんでいるので、OSは物理デバイスがHDDでもUSBメモリでもおなじ方法でファイルを読み書きすることができます。

FUSE(RESTfs)

FUSEの上に構築されたRESTfsの場合はどうでしょう。例としてTwitterのAPIをマウントしている場合を考えてみます。

RESTfsがOSに組み込まれたFUSEからopen, read, write, closeというインターフェイスで呼び出されるところまでは同じで、そこから先が異なります。OSからの要求を受け取ったRESTfsは、その要求をTwitterモジュールに送ります。TwitterモジュールはTwitterというウェブ上のサービス固有の認証方式や、アクセスする方法(GET/POST/PUTなど)、アクセスするべきAPIのURLやメソッド名を管理しています。

これはちょうど物理デバイスのデバイスドライバが、物理デバイスひとつひとつに固有のコマンドレジスタのアドレスやコマンドを管理しているのに似ています。

SITEINFOとAutoPagerize/LDRize

ウェブのサービス固有の情報をそれぞれ管理してなんらかの機能を実現しているもの、で思いつくのはAutoPagerize – Userscripts.orgとLDRize – Userscripts.orgです。

AutoPagerizeはウェブ上のサービスごとに異なるページの内容と次のページをXPathで表して、ブラウザでページの一番下までスクロールしたときに自動的に次のページの内容を今表示しているページにjavascriptでくっつけています。この各ウェブ上のサービスごとに記述されたXPathはSITEINFOと呼ばれています。LDRizeも同様に、ページの中のパラグラフ、そのページでリスト表示されているデータのひとつひとつをXPathで表して、キーボードのj,kでパラグラフを移動できるようにしています。

この仕組みをデバイスドライバと比較して下のような図にしてみました。

Firefoxとそのドライバに必要とされるインターフェイス

いままでのOSは、コンピュータ上でよく行う操作をopen, read, write, closeというインターフェイスで抽象化していました。AutoPagerize,LDRizeはそれぞれ次のページを見ると次のパラグラフ見るという操作を目的として作られていますが、この二つはブラウザ上でよく行う操作であることに気がつきました。

多くのウェブページは大量の情報を表示する方法として、ひとつのページに何十件かの情報を表示して、表示しきれなかった部分は次のページにわけて全部のデータを表示する方法を採っています。結果として、ウェブを見るときには、自分が探している項目が出てくるまでリスト表示されている項目をひとつずつ見て、そのページになければ次のページをロードしてまた項目をひとつずつ見る、という操作を頻繁にしています。

AutoPagerize,LDRizeは、ブラウザ上でよく行われる次のページを見ると次のパラグラフ見るをという操作をそれぞれインターフェイスとして持っていて、ページの一番下までスクロールしたときと、キーボードのjを押したときにFirefoxから呼び出されるようになっています。

OperaのFast Forwardもこの次のページを見るというインターフェイスをAutoPagerizeとは異なるアプローチで実装していると考えることができます。

AutoPagerize/LDRize

ブラウザから次のページを見るという要求を受け取ったAutoPagerizeは、要求を完了するために、次のページを取得してページを構成している要素(pageElement)を取り出して現在のページに繋げます。そのためには現在表示されているページのDOMツリーの中でどの部分がpageElementかを知る必要があります。

LDRizeも同様に次のパラグラフ見るという要求を受け取ったときに、DOMツリーのどの部分がひとつひとつのパラグラフ(paragraph)かを知る必要があります。

pageElementもparagraphも、ウェブページによって異なっているので、AutoPagerize/LDRize本体とは切り離されて外部のSITEINFOによって管理されています。これはちょうどFDSが膨大な数が存在する個別の物理デバイスのパラメータを持たずに、物理デバイスの操作はデバイスドライバに任せているのに似ています。

AutoPagerize/LDRizeも、無限にあるウェブサイトごとに必要なパラメータを内部に持たずにSITEINFOに任せていると見ることができます。

SITEINFO

SITEINFOはOSのデバイスドライバと同様に、たぶん一番めんどくさいところをなんとかしてくれています。対応しないといけないものはたくさんありますし、対応してもウェブページの側が新しくなって動かなくなったりもしますし、間違って記述されていると機能そのものが変になることもあるのはデバイスドライバと本当に似ています。ほんもののデバイスドライバと違って開発もデバッグも難しくはないところはいいところです。

ブラウザ上で頻繁に行うその他の操作

ほかにブラウザ上で頻繁に行っている作業がないかと考えてすぐに思いついたのは、ページの中から情報の本体に当たる部分を見つけ出す作業です。普段は意識しませんが、ページの中にはサイトのロゴであったり、タイトル、ほかのページへのナビゲーション、フッタ、広告枠、と、様々な情報本体以外の部分があり、その中からページに固有の情報を抜き出す作業を意識せずにやっています。PlaggerのFilter::EntryFullTextは、このインターフェイスを実装したドライバだと考えることができます。EntryFullTextはSITEINFOと同様、ページに含まれる情報の本体がどこにあるかをyamlファイルに記述して、無数のウェブページに対応しています。

まとめ

Web Operating Systemという言葉から、そのストレージが何かということと、そのストレージのドライバはどんなものになるかについて考えてみました。

open, read, write, closeというインターフェイスはコンピュータ上で頻繁に行われる操作をうまく抽象化することができました。ブラウザ上で頻繁に行われる操作というのは、まだ歴史が浅くどのようなインターフェイスが考えられるのか模索されている段階だと思われますが、次のページを見る、次のパラグラフ見る、という操作は紙媒体の時からずっとあるインターフェイスでもあり、今後も残っていくのではないでしょうか。

AutoPagerize/LDRizeはそのインターフェイスを実装しているのだと考えることができます。そして、無数のウェブページに対応するためにSITEINFOという抽象化層があり、この抽象化層はWeb Operating Systemにおいて、ストレージからデータ
を読み出すためのデバイスドライバの役割を果たしているということができそうです。

GRDDL

SITEINFOと同様にページの中から特定の情報を抽出する標準的な方法としてW3CがGRDDLの草案を公開しています。GRDDLについてはXHTMLからメタデータを自動抽出するや名前のウェブとXHTML文書のプロファイルで説明されています。