dwps-1

• dwpsに戻る

dwps-1(仮)

「Dynamic Webservices Provider Specification - version 1」の略。この名前は仮のものなので、将来に変更される可能性が高い。

まだ作成中。

• 紹介
• 目的及び概要
• 要求
• 用語定義
• 仕様
• 名前空間
• dwps-pathからts-pathへのマッピングルール
• tsのnodeに設置できるファイルの一覧
• ほげ
• 適切なHTTPヘッダ
• dwps実装が提供すべきユーティリティ手続き
• 現行の仕様の問題点
• バッドノウハウ

紹介

目的及び概要

• dwpsを参照。

要求

• dwpsを参照。

用語定義

url

HTTPで利用するurl。ここでは単なるpath文字列ではなく、httpやhttps等のscheme名から始まるものとする。末尾にQUERY_STRING文字列がついていてもよい。

dwps実装

このdwpsの仕様を実装したシステムの事。例えば、dwps-1実装がCGIとして実装されているのであれば、そのurlは「 http://example.net/hoge/dwps.cgi 」のようになるだろう。勿論、CGI以外の方法で実装しても良い(例えばhttpdそのものとして実装するとか)。

dwps-path

前述のurlの内、dwps実装が利用すべきpath部分と、(もしあるなら)そのQUERY_STRING部分。例えば、urlが「 http://example.net/hoge/dwps-1.cgi/fuge/?action 」であるなら、dwps実装が扱うべき情報は「/fuge/?action」という事になる。ちなみにこの例は「/fuge/」というts-pathと、「action」というactionを示している。

ts

tree-storageの略。(ファイル的な)各種のデータを、tree構造のpathに対して保存するストレージ。ここでは主にosのファイルシステムそのものを利用する事を前提としている。しかし代わりにdbmやrdbmsや各種のバージョン管理システム等を利用してもよい。「ts-path」の項目も参照。

ts-path

前述のtsの、ファイルのpathに相当するもの。tree構造である事(つまり、各nodeが自分自身の子要素の一覧を容易に取得可能である事)。pathは「/」区切りで、case sensitiveで、最大で1023byteの長さで、その各要素は255byte以下である事。これを満たさない場合は、そのストレージはtsとして利用するのに適さない(仮)。

rs

repository-storageの略。tsとは別に用意される、フラットな構造のストレージ。基本的には「共有されるべきもの(例えばhtmlテンプレートの一部等)」及び「ロジック的なコード(の内部表現)」といったものが保存される。ロジック的なコードの保存については(文字列として保存するのであれば)バージョン管理システムと相性が良く、また、tree構造が不要な点はdbmによる管理にも向いている。

rs-path

前述のrsのkeyの事。フラットな構造であるが、人間が管理する際の便宜の為に、カテゴリによる前置句をつけて管理するのが結局推奨される(為、見た目的にはpathのように見える)。

action

主に、urlに対する「操作」を指示する為の文字列、或いは指示そのものの事。urlもしくはdwps-path末尾のQUERY_STRING文字列として渡されるか、もしくは、HTTPリクエストのPOST時のパラメータに一緒に含められて渡される。省略可能。

us

user-storageの略。ストレージ自体がユーザ(アカウント)単位で分けて管理されている、フラットな構造のストレージ。この中に任意のkeyとvalueを保存できる。個人(アカウント)に属する情報を保存する目的。複数のusを用意し、目的によって使い分けてもよい。

gs

gc-storageの略。セッション等の、一定時間経過によって自動削除されるべきデータを保存する為の、フラットな構造のストレージ。複数のgsを用意し、目的によって使い分けてもよい。

仕様

名前空間

dwps実装は、以下の名前空間を扱う必要がある。 必要であれば、これら以外に更に名前空間を用意してもよい(例えば、使用するプログラミング言語内でのモジュール空間等)。

dwps-path

アクセスされたurlから得られる、dwps実装内の各ページに対するlocator。 tree構造を持つpathと、actionを指定するQUERY_STRING文字列の、二つの情報を保持している。 詳細については、「用語定義」のdwps-pathの項目を参照。

ts-path

dwps-pathからマッピングして得られる、tsに保存されている実体のpath。 詳細については、「用語定義」のts-pathの項目を参照。

rs-path

フラットな、多目的ストレージのkey。 詳細については、「用語定義」のrs-pathの項目を参照。

dwps-pathからts-pathへのマッピングルール

1. まず、dwps-pathから、path部とaction部を分離する。
2. path部を、path区切り文字である「/」で分割する。path部は常に「/」で始まるので、最初の空要素は除外する。また、path部の末尾が「/」で終了している場合も、同じように最後の空要素を除外する。
3. 分割したpath部のそれぞれに対して、以下の置換処理を行う。
   • まだurlエンコードされた状態(%nn)の筈なので、urlデコードを行う(この操作は前述の分解よりも後に行う必要がある、何故なら「%2f」が出現する可能性がある為)。
   • ts-pathとして使えない/使いづらい文字があるなら、それをurlエンコードに置き換えておく(例えば、マルチバイト文字や「/」や「~」や「*」や「%」など)。この際のurlエンコードに出現するa-fはlower caseにする事。
4. 置換処理が完了したら、
5. 分割したpath部を、先頭から順に、対応するts内のディレクトリ(相当)に対して、以下のルールで確認していく。
   • ディレクトリ(相当)が存在しない場合は、設定に準じたpath-not-foundハンドラに制御を渡す。存在する場合は以下の判定を行う。
   • ディレクトリ(相当)の中に、「.dwps-env」ファイル(相当)があれば、そのファイルの内容を読み込み、設定として(今回のリクエストに対する)環境に反映する。その後、以下の判定を行う。
   • ディレクトリ(相当)の中に、「.dwps-map」ファイル(相当)があれば、そのファイルの内容を実行し、その結果をそのまま返す。その際には、まだ未処理だったpath部を引数として渡す(以下の「再帰的に処理」は行わない事になる)。
   • ディレクトリ(相当)の中に、「.dwps-map」ファイル(相当)がなければ、残っているpath部の次のディレクトリ(相当)を再帰的に処理する。
6. 上記の操作を繰り返し、分割したpath部の最後の要素に到達した場合は、最後のディレクトリ(相当)に対して、以下の判定を行う。
   • 行うべきactionを決定する。action部が指定されているなら、それを採用する。そうでない場合は、設定に応じて、適切なdefault値を採用する(default値の推奨は「view」)。これを仮に「%HOGE%」とする。
   • 「.dwps-act.%HOGE%」が存在するかを調べる。存在する場合は、それを実行し、その結果を返す。
   • 「.dwps-act.%HOGE%」が存在していない場合は、設定に準じたaction-not-foundハンドラに制御を渡す。

大雑把に要約すると、以下のようなマッピングが行われる事になる。

• dwps-pathが「/」の場合、ts-pathは「/.dwps-act.view」
• dwps-pathが「/?edit」の場合、ts-pathは「/.dwps-act.edit」
• dwps-pathが「/fuge」の場合、ts-pathは「/fuge/.dwps-act.view」
• dwps-pathが「/fuge/」の場合、ts-pathは「/fuge/.dwps-act.view」
• dwps-pathが「/fuge/?send」の場合、ts-pathは「/fuge/.dwps-act.send」
• dwps-pathが「/~abc/」の場合、ts-pathは「/%7eabc/.dwps-act.view」
• dwps-pathが「/%7Eabc/」の場合、ts-pathは「/%7eabc/.dwps-act.view」
• dwps-pathが「/a%5fb/」の場合、ts-pathは「/a_b/.dwps-act.view」

tsのnodeに設置できるファイルの一覧

あとで

ほげ

あとで

適切なHTTPヘッダ

あとで

dwps実装が提供すべきユーティリティ手続き

あとで

現行の仕様の問題点

何か良い解決方法を思いついたら、将来のバージョンにて対応するかもしれない。

• ts-pathのnodeに設置されるファイル名が分かりにくく、しかも長い。もっと良い命名基準その他があるなら、変更したい

• (ts-pathによる)各ページから共有されるページ内オブジェクト(例えば、タイトルロゴやメニュー等)は、完全にロジック化されたコードとも違うので、rsに保存するのは微妙ではないか？
  • これらのタイトルロゴやメニュー等は、(ts-pathによる)urlとしてのエントリは持っていない為、通常のテンプレートとは扱いが微妙に違う為、「仮に」(ロジック類と同じように)rsに保存する事にした。これは正しいマッピングとは言えない、が、だとすれば、どのようにマッピングすべきなのか謎。
  • php/asp/jsp等では、以下の構造のどれかになっているが、どれも「常に正しいマッピング」とは言えないような気がする。
    1. *.php内にテンプレート有り。ページをまたぐロジックはlibディレクトリ内に書く。タイトル等の共有テンプレートはincludeディレクトリ内に設置。
       • おそらく一番「正しいマッピング」に近いモデル。だが開発を進めるにつれスパゲッティ化しやすい。
    2. *.php内にテンプレート無し。テンプレート類は共有のものも含めてincludeディレクトリ内に設置。ロジックはlibディレクトリ内に書く。
       • この場合、各*.phpはほぼエントリポイントとしての意味しか持たない。すっきりしており、ロジックとテンプレートがごっちゃにはならないが、エントリポイントと個別(共有しづらい)テンプレートは大体の場面で一対一で対応するので、ここを分離するのはちょっと無駄なコストに感じられる(しかし、1と比べてややスパゲッティ化しづらい)。
  • おそらく、前述の1の方法が近いようだ。つまり、ロジックはlib、共有テンプレートはincludeに。よって、空間を分けるべきではないのか？しかし、その為だけにもう一つ用意するほどとも思えない……。
  • この件については、もう少し考える。
    • この件は結構根が深いようなので、別ページで考える。→path→funcマッピング問題
• rsにはロジック的なコードが保存され、それはインクリメンタル開発されたり、ライブラリとして参照されたりすると思われるが、そうなった場合、それぞれのコードへのアクセス性が良くないと開発に支障をきたす。例えば、全文検索して該当するファイルを順に開いたりのような操作が必要になると思われるが、そのような使い方において、通常の開発用エディタに太刀打ちできるレベルにまでもってこれるかというと、ちょっと無理だと思う。これでは使い物にならないのでは？

バッドノウハウ

• apacheにおいて、アクセスされたurlからdwps-pathを取り出す際に、CGIメタ変数PATH_INFOを参照してはならない。何故なら、これは既にurlデコードされてしまっている為。REQUEST_URIから切り出すようにしなくてはならない。
• apacheにおいて、PATH_INFO部にurlエンコードされた「%2f」が含まれている場合、強制的に404を返す挙動がある(但し、バージョンによる)。これを修正するには、「AllowEncodedSlashes On」の設定を行うか、パッチを当てて修正すればよい。
  • http://d.tir.jp/pw?bk-apache#H-zn7hd6 辺りを参照。