dps:swmflrr

←dps

「swmflrr」とは、「sexpr with metadata format like reversed rfc822」の略。

dpsでデータを実ストレージに格納する際の書式である。

• 仕様
• メリット
• デメリット
• サンプル
• TODO
• 古いメモ

仕様

• 複数の改行で分割された、複数のS式(の外部表現)を含む、一つの文字列である
  • 改行は、CRLF、もしくはLFであるものとする(仮)
• encodingはutf-8とする
• 最初の行には、一つのS式(の外部表現)のみが記述される。これがデータ本体となる
• 最初の行以外には、一つの行につき、以下のようなdotted pairが一つ記述される。これは、rfc822における、ヘッダのような役割を果たすメタデータ定義となる。
  • dotted pairのcar部は任意のS式でありキーとして使われる。
  • dotted pairのcdr部はlistであり、任意の(複数個の)値が含まれる。
• 行の末尾は必ず改行である事(ファイル末端、文字列末端、通信バッファ末端であろうと例外なく)
  • これは、通信断などによる、予期せぬ終端かどうかを判定する為に必要なルールである
• 一つのファイル、文字列、通信バッファに、複数のswmflrrを入れる事も許容する。
  • その際には、swmflrrとswmflrrの間に、空の改行のみの行(rfc822でのheaderとbodyの区切りと同じもの)をはさむ事。

メリット

• メタデータをつけられる
• rfc822形式と比較して、データ本体をファイルやport等から読み込む際に、ヘッダの終わりの確認する必要がない
• 本体データのみを別のところに転送する際に、一旦全部読み込む必要がない

デメリット

• メタデータのみの更新ができない(メタデータのみの更新であっても、エントリ全体の更新とするしかない)
• 本体データが大きい場合に、メタデータだけ参照したい時であっても、本体データを読み飛ばす必要がある(といっても、最初に出現する改行を探すだけだが)

サンプル

• サンプル1

  "これは、\nメッセージです。"
  ("Subject" "タイトル")
  ("Date" "Mon, 28 Mar 2011 02:03:03 +0000 (UTC)")
  ("From" "だれか@どこか")
  ("To" "俺@ここ")
  ("Content-Type" "text/plain; charset=UTF-8")
  

• サンプル2

  #0=(1 2 . #0#)
  (desc "これは循環リストです")
  (include 1 2)
  (exclude)
  (proper-list? #f)
  

TODO

• BNF化する事
• メタデータのkey部は任意のS式ではなく、文字列かシンボルかkeywordかのどれかに固定すべきかも(迷ったり間違わないように)
  • もうちょっと考える

古いメモ

• メタデータ部の書式はalist？それともkeywords？
  • keywordsの方が人間が読み書きしやすいが、今回は人間が読み書きする用途ではないので、alistで行く事に