リモートファイルに対しては、作成と置換のみを行う必要があるかもしれない(ローカルファイルに比べてリモートファイルのランダムアップデートはあまりに遅く、実装も難しくなる可能性があるので、リモートファイルの更新は意味をなさない)。リモートファイルに対して部分的な読み込みと書き込みを行う必要があるかもしれない(少なくともリモートファイルモジュールの内部では通信中断後のダウンロードとアップロードの再開をできるようにする必要がある)。しかし、ローカルキャッシュを利用している場合を除き、ランダムリードは適さない。概念的なそれぞれのインターフェースに対してリモートファイルサーバーを設計するときは、上位レベルモジュールが要求するサービスのレベル(必ずしも全てが要求されるわけではない)を良く考える必要がある。そして、どのようにリモートファイルサーバーの機能を実装するかだけでなく、アプリケーション内に既に存在するファイルサービス(ローカルファイル、既にあるクラウドクライアントなど)と新たしいリモートファイルサーバークライアントの間で整合を取るかについても同様に考える必要がある。必要なインターフェースの設計が完了したら、リモートファイルサーバークライアントはこれらのインターフェースを実装すべきである。また、既に存在するローカルファイルに対しての機能(例えばファイル更新など)について制限を加えたい場合、同じ抽象インタフェースを提供するローカルまたは他の既存のリモートファイルアクセスモジュール用のアダプタを記述する必要があるかもしれない。また、コンピュータ上に構成されている利用可能なファイル互換システムを検索するために独自のファイルアクセス列挙子を記述しておく必要もある。これらが完了すると、アプリケーションはドキュメントをローカルとリモートに透過的に保存する事が可能になる。さらに簡単に言うと、新しいファイルアクセスインターフェースを使用している上位レベルモジュールは使用の際にローカルとリモートファイルにアクセルするシナリオを意識する必要がなくなり、再利用性が向上する。注意:多くのOSがこの手の機能を実装し始めているため、新規実装のクライアントをこの既に存在している抽象モデルへ適用するのは控えた方が良いかもしれない。