目次
WebDAV はHTTPの拡張で、ファイル共有のための標準として ますます一般的なものになっていっています。今日のオペレーティング システムは極端に Webを意識していて、多くのOSはWebDAVサーバによって 公開された「共有」 をマウントするための仕組みを組み込みで サポートしています。
もし Apache/mod_dav_svn をSubversionネットワークサーバとして 利用するなら、ある程度 WebDAVサーバも実行しなくてはなりません。 この補遺は、このプロトコルの性質についてのいくつかの背景を与え、 Subversionがどのようにそれを利用し、WebDAVを考慮しているほかのソフト とどのようにうまく協調するかを示します。
この節はWebDAVの背後にあるアイディアについての、とても簡単で 一般的な概要を示します。それはクライアントとサーバの間のWebDAV の互換性に関する問題を理解するための基礎になります。
RFC 2518 はいくつかの概念と、それにともなうHTTP 1.1 の 拡張メソッドを定義しています。それはweb をもっと普遍的な読み書き 可能な仕組みにするものです。基本的なアイディアはWebDAV互換のウェブ サーバは、一般的なファイルサーバのように振る舞うことができるという ことです。クライアントはWebDAVの「共有」をマウントする ことができ、NFSや、SMB共有のように動きます。
しかしながら、RFC 2518 は、DAVの文字列中の「V」にもかかわらず、 どんなタイプのバージョン管理のモデルも提供してはいない ということを知っておくのは重要です。基本的な WebDAVクライアントとサーバは ファイルやディレクトリの一つのバージョンのみが存在するのが前提となっていて、 繰り返し上書きすることができます。
基本的な WebDAVで導入された新しい概念とメソッドは:
WebDAV の世界ではサーバ側にあるすべてのオブジェクト (それは URI によって記述されるものですが)は、 リソースと言われます。
標準的なHTTP PUT
メソッドに
加えて(それはwebリソースを作ったり上書きしたりしますが)、WebDAV
は新しいCOPY
と MOVE
メソッドを定義し、リソースを複製したり移動したりすることができます。
集合 は WebDAV の用語では
ひとまとまりのリソースのことを言います。ほとんどの場合、それは
ディレクトリのようなものになります。ファイルリソースは
PUT
メソッドで書き込まれたり作られたりしますが、
集合リソースは新しい MKCOL
メソッドで作られます。
これはSubversionに出てるのと同じアイディアです—
ファイルと集合に付随したメタデータです。クライアントは新しい
PROPFIND
メソッドを使ってリソースに付随
した属性を一覧表示したり抽出したりできます。そして、
PROPPATCH
メソッドを使って変更できます。
いくつかの属性は完全にユーザによって作られ制御されます(
たとえば、「color」と呼ばれる属性)、また他のものは
完全にWebDAVサーバによって作られ制御されます(たとえば、ファイル
の最後の修正時刻を含む属性)。最初のものは「死んだ」
属性と呼ばれ、あとのものは「生きた」 属性と呼ばれます。
WebDAVサーバはクライアントに対するロックの機能を与える
ことができます。
—この機能は任意です。ほとんどのWebDAVサーバはこの機能を
提供していますが。もし存在すれば、クライアントは新しい
LOCK
と UNLOCK
メソッドを
使ってリソースへのアクセスを調停することができます。
ほとんどの場合、これらのメソッドは排他的な書き込みロックを作る
ために利用されます(「ロック・修正・ロック解除の解法」で議論した
ように)、ただしサーバの実装によっては共有書き込みロックも可能です。
より最近の仕様(RFC 3744)では WebDAV リソースに対するアクセス制御 リスト(ACL)を定義するためのシステムを規定しています。クライアントや サーバによってはこの機能を実装し始めているものもあります。
RFC 2518 はバージョン化の概念がないので、 他の機能グループは RFC 3253 にまかされました。それは、 WebDAVにバージョン化の機能を追加したものです。この部分は「DeltaV」 と呼ばれます。WebDAV/DeltaV クライアントとサーバはしばしば単に「DeltaV」 クライアントとサーバと呼ばれます。DeltaVは基本的なWebDAVの 存在を含んでいるからです。
DeltaV はまったく新しい単語を導入しましたが、 びっくりしないでください。考え方は非常に直接的です:
CVSや他のバージョン管理システムのようにDeltaVはそれぞれのリソースは
無限の数の状態をとりうると仮定しています。クライアントは新しい
VERSION-CONTROL
メソッドを使ってリソースを
バージョン管理下に置くことによって始めます。これには新しい
VERSION-CONTROL
メソッドを使います。
DeltaV サーバによっては仮想的な作業スペースをサーバ上に作る能力が
あります。すべての作業はそこで実行されます。クライアントは
MKWORKSPACE
メソッドを使ってプライベートな領域を
作り、作業スペースに「チェックアウト」することで
特定のリソースを変更したいということを示し、編集した後、もう一度
「チェックイン」します。
HTTPの言葉で言えば、メソッドの
流れとしては、
CHECKOUT
, PUT
,
CHECKIN
となります。
DeltaV サーバによってはクライアントがローカルディスク上にプライベート
な作業コピーを持つこともできるという考え方をサポートします。
クライアントがサーバに変更点をコミットしたい場合、まず MKACTIVITY
メソッドによって一時的なサーバトランザクション( アクティビティー
と呼ばれます)を作ることで処理を開始します。
それからクライアントは変更したいリソースごとにCHECKOUT
を実行し、PUT
要求を送ります。最後にクライアントは
リソースに対する CHECKIN
を実行するか
MERGE
要求を送ってすべてのリソースを一度に
チェックインします。
DeltaV では「設定」と呼ばれるリソースの 汎用的な集まりを定義することができますが、かならずしもそれは特定の ディレクトリに対応する必要はありません。設定はファイルの特定のバージョン を指し示すのに作成したり、「ベースライン」のスナップショット を作ったりできます。後者はタグによく似たものです。
DeltaV は新しいメソッドREPORT
を定義しますが
それはクライアントとサーバが独自データ交換を実行するのを許す
ものです。DeltaV はクライアントが要求可能な標準化された履歴情報
をいくつも定義してありますが、さらに自由にカスタム情報を定義することも
できます。クライアントはREPORT
要求を
独自のデータのある属性ラベルの付いたXMLのボディーをともなって
送信します。サーバがこの特定のレポート型を理解できることを
仮定して、それはやはり独自のXMLボディーを応答します。この技術は
XML-RPCとよく似ています。