現在のバージョン： 0
最終更新日 ： 1999年６月７日
Step 0:
ドラッグが始まる前に、ソースが、ウィンドウ・プロパティを作成し、text/plainタイプ(必要であればcharset属性も含む)の XdndDirectSave がユーザーがセーブしたいと思うファイル名(パス無し)を貯えます。
ソースは、XdndActionPrivate にアクションを明細に指示すべきであります。
ファイルマネージャーが XdndPosition を受ける時、もしターゲット・ディレクトリーが書き込み可の状態であれは、ドロップのみを受け付けます。マウスがアイコン、又は書き込み可のディレクトリー名の上空にいる場合、これが、ターゲットとなり、アイコンがハイライトされます。さもなければ、ターゲットは、ウィンドウ上に表示されたディレクトリーであります。たとえウィンドウのディレクトリーが書き込み可の状態でなく、そのサブディレクトリが書き込み可だとしても、ソースに連続してフィードバックが与えられたのなら、問題を引き起こしません。
Step 1:
ファイルマネージャーが XdndDrop を受けたとき、最初に、XdndDirectSave をチェックします。それがこれが与えられなかったならば、 text/uri-list を退避させます。
もしそれが XdndDirectSave ターゲットを見つけるならば、それがソースウィンドウの XdndDirectSave プロパティ (2)、よりデータを取り戻します。それを URL （名前 -> file://host/path/name ）に変えて、これを XdndDirectSave プロパティ (2)、に置いて、もし必要であるならばキャラクタ・セットと一致するタイプに変更し、ソースからの XdndDirectSave をリクエスト (7) します。
Step 2:
ソースが XdndDirectSave のリクエストを受け取って、その XdndDirectSave プロパティ (2) からデータを取り戻し、そして、指示されたロケーションへデータを保存することを試みます。
もし成功するならば、一つのキャラクタ S（ 0x53 ）を含む XA_STRING タイプのデータで、ターゲットのリクエストに答え、成功(success)を知らせます。
もし、ロケーションを指示して使いたい場合、それは不可であります。何故ならば、異なるマシン上であるためで、キャラクタ F（ 0x46 ）を含む XA_STRING タイプのデータを応答し、失敗(Failure)を知らせますファイルマネージャーがさらに応答を待ちます。
もし、ロケーションを指示したデータのセーブを拒んだ場合(異なるマシン上に保存するのが許されないのは、ファイルの内容がリロケータブルでない為です)、キャラクタ E（ 0x45 ）を含む XA_STRING タイプのデータを応答し、エラー(Error)を知らせます。
Step 3:
ファイルマネージャーは、その結果を受信します。
もしそれが S を受信するならば、 新しいファイルを表示すためにディスプレーをリフレッシュして、XdndFinished を送信します。
もしそれが F を受けるならば、 application/octet-stream タイプのデータをチェックします。これが利用可能な場合、これを取り戻し、ファイルのセーブを試みます。成功の場合、ディスプレーをリフレッシュします。さもなければ、ソースウィンドウの XdndDirectSave プロパティを長さ０(zero length)に変え、失敗(failure)を知らせます。(1)そして、XdndFinished を送信します。
もしそれが E を受けるならば、XdndFinished を送信します。
Step 4:
ソースが、XdndFinished を受信します。
もしそれが S か F を送るならば、その XdndDirectSave プロパティをチェックします。これが空の状態でない場合、ソースはファイル名とパス名を更新し、これを保存し、"要セーブ"(nees save)フラグをクリアーします、（どちらの場合もプロパティは空の状態です。注に説明有り）。
送ったか、受け取ったにも関わらず、終了時、XdndDirectSave プロパティを削除する。（XGetWindowProperty()コールで行なわれます)
もしディレクトリーブラウザを提供しないのであれば、インターフェイスは、次に述べる通りになるかもしれません。
他のアプリケーションが、このプロトコルを使うことができます。実際のデータをリクエストする前に、XdndDirectSave ウィンドウ・プロバティの内容を単純に取り戻し、データ自身に加えて、データの名前を必要とする場合です。
もしプログラムが、容量の大きいデータ（ビデオクリップ等）を待ち受ける場合、Ｘ Selection 経由の代りに、ディスク上のデータを受けるには、原則としてファイルマネージャーの振りをします。この場合、ステップ３の通りプロパティを長さ０(zero length)にセットし、ソースが、データが保存されたと認識しないためです。ソースが、同じマシン上であれば、これは有効でありますが、通常は、ターゲットが単純にソースにより書かれたファイルの修正個所を調べるだけのPublish-Subscribe プロトコルを使うのが良い場合があります。
以下に述べる全定数の、大文字で表示した部分は、Ｘアトムのストリング名です。グローバル・レジストリを要求するのに、ハード・コーディングする必要がありません。
これは、ウィンドウ・プロパティとデータ型の両方であります。どちらの場合も、アトムの名前は、XdndDirectSave0
であります。バージョン・ナンバーが、将来的なプロトコルの新しいバージョンを可能とするように、この名前の中に入っています。
全てのアプリケーションが、このプロトコルの以前のバージョンをサポートする必要があります。ファイルマネージャーは、サポートされる最新バージョンの
XdndDirectSave から利用可能なデータタイプのリストを検索します。そして、最新バージョンを見つけるたならば、それを使用します。これは、XDND
プロトコル と同様な方法であります。直接保存すると、バージョン・ナンバーは、ウィンドウ・プロパティが保存されるのに代わって、アトム名であります。後の方法は、サーバーへの往復旅行を必要とします。
もし必要であれば、ウィンドウ・プロパティは、charset 属性を含む、text/plain タイプでなければなりません。これにより、ファイルシステムが取り扱うことができるどのようなキャラクタも、ファイル名に含ませることができます。ファイルマネージャーが取り扱うことができないキャラクター・セットは、ドロップを拒否されます。アプロケーションが取り扱うことができないキャラクター・セットは、ファイルマネージャーより、これをエラーとして処理し、E の値を戻します。（ 具体例[walk-through] のステップ２を参照の事）charset 属性が設定されていなければ、これを iso8859-1 として取り扱います。
application/octet-stream
このデータタイプは、プログラムがディスクに書く正確なフォーマットのデータを供給するために予約してある。
たとえ、あなたが無から直接保存(Direct Save)を実装するとしても、あなたが配布するものに、このプロトコルをサポートしていると、はっきりと述べている文章と、しかも、このウェブ・ページへのリンクが含まれているとしたら、非常に有りがたい事です。雪玉が回るのを助けるでしょう。より多くのアプリケーションが同じプロトコルをサポートすれば、ユーザにとって直接保存(Direct Save)はより利用価値の高いものとなるでしょう。あなたが、このプロトコルをサポートした場合、お伝え下さい。サポーター・リストへ追加致します。
初版