最小抽象ファイルシステム（Minimum Abstract Filesystem; mafs）の仕様案を述べました。
なんでこんなことを考えたのかを書いてみます。
コンピュータに直接付いているローカルディスクだけではなく、LAN内のファイルサーバーやネットワーク型ストレージデバイスもファイルシステムとして使えます。インターネットでも、WebDAVのようなプロトコルでリモートストレージをファイルシステムのように使えます。最近では、プレーンなHTTPだけで使えるストレージサービスもあります。
そういう状況ですから、「ローカルか、リモートか」とか、「ストレージの実体が何であるか」とかを気にせずに使えるファイルシステムAPIがあったら便利だろうと思ったわけです。特に、HTTP通信を経由して使うことを意識して考えてみたのが mafs です。
HTTPを前提にすると、mafsを実装する場所は2箇所、すなわちHTTPサーバー側とHTTPクライアント側があります。どちらか一方の実装もあるでしょうし、両側に実装することもあるでしょう。
僕がこんなことを考えたきっかけはGoogle App Engine（GAE）なので、GAEを例に説明します。
GAEは書き込み可能なファイルシステムを持たないので、ファイルを使ったプログラムをGAE上で実行するのは不可能です。しかし、Google Datastoreというキーバリュー・データベースを持っているので、Datastore上でファイルシステムのエミュレーションをすることは可能でしょう。とはいえ、あまりに複雑なファイルシステム機能を実現するのは負担です。最小限の機能でも、ある程度の実用に耐えるでしょう。
そこで、最小限のファイルシステム機能を特定したいと思ったわけです。また、HTTPを使ってファイルシステムにアクセスするとき、「HTTPリクエスト → ファイルシステムAPI呼び出し」というマップが、できるだけ素直で直接的にできるようにしたかったのです。
GAE Datastore上にPythonかJavaでmafsを実装すれば、次のようにして「HTTPリクエスト → ファイルシステムAPI呼び出し」のマップができるでしょう。
| HTTPメソッド | パス末尾のスラッシュ | リクエストボディ | リソースが既に存在する | mafs関数 |
|---|---|---|---|---|
| PUT | なし | どちらでも | NO | createFile*1 |
| PUT | あり | なし | NO | createDirectory |
| DELETE | どちらでも | なし | YES | delete |
| GET | なし | なし | YES | readFile |
| GET | あり*2 | なし | YES | readDirectory |
| PUT | なし | 普通はあり | YES | writeFile |
| HEAD | どちらでも | なし | YES | readMetadata |
メタデータの書き込み（setMetadata, updateMetadata）はどうやってマップするか悩んでいるんですけどね ^^; HTTPやRESTに詳しい方、教えてぇー（拡張ヘッダフィールドを設けたり、メタデータの置き場所としてリクエストヘッダだけじゃなくて、リクエストボディも使用するってことになるのかも。）
HTTP経由のフィイルシステム操作の約束事ができれば、HTTPクライアント側にもmafs APIを実装することができます。例えば、クライアント側のcreateFile関数は、適切なHTTPリクエストを組み立てて、サーバー側のcreateFile関数を呼び出すようにすればいいわけです。
もし、ストレージ・バックエンドにAmazon S3を使うならば、mafs APIの実装はS3クライアント側で行うことになるでしょう。RDBをバックエンドに使うなら、mafs APIをSQL文にマップするプログラムを書くことになるでしょう。もちろん、本物のディスク・ファイルシステムをラップしてmafsを実現してもかまいません。
ファイルシステムの使い方が素朴で初等的である（つまり最小）なら、かなり広範囲に渡る柔軟な可搬性が手に入ると思います。
