namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

Rei FURUKAWA <furukawa@xxxxxxxxxxxx> wrote:

>mknmz を深く使いこなしていないので、よく分かっていないのですが、NMZ.f
>のファイル名は、REPLACE か何かで、他のものに置き換わる場合はありますか？

えっと、質問の意味がわかりません。ファイル名がなぜ重要なので
しょう?


>satoru-t> 統合すればいいんじゃないかと考えています。NMZ.field.summary 
>satoru-t> を追加するなりして。
>
>今までは、NMZ.field.* の用途は「フィールド検索」だけだったので、ファイ
>ルの頭から読めばよかったですが、「タイトルによるソート」などをやろうと
>すると、文書番号からタイトルが引けないといけないですよね。そうなると、
>NMZ.field.title.i (仮称) が欲しくなりそうです。

その通りです。

# NMZ.field.size を新設したとして、サイズによるソートを考え
# ると、 numeric なソートを考慮する必要がありますね。あるい
# は桁数を決めて頭に空白を埋めておくとか。(commaもあらかじめ
# 打っておくと後が楽かな)


>他のフィールドでもソートできるようにしようと思うと (思わなければ別に
>いいのですが) それぞれのフィールドについて NMZ.field.*.i が欲しくなり
>そうです。

そうです。また、検索結果の表示の際に NMZ.field.* から現在の 
NMZ.f に相当する情報を動的に組み立てるには NMZ.field.*.i が
不可欠です。


>と、考えると、逆に、NMZ.field.* を廃止して、NMZ.f + NMZ.fi に統合した
>ほうが、いいのではないか、と思います。

うーん、 2つの方法を比べると、

NMZ.field.* + NMZ.field.*.i に統合する方法

  利点
    * フィールド指定の検索が高速 (今まで通り)
    * 拡張性が高い
      - 不要なフィールドは後から削除できる (ファイルを消すだけ)
      - 新しいフィールドを後から追加できる (必要とあれば)
      - 既存のフィールドの情報は後から更新できる 
        (インデックスをつけ直す必要はあるが - NMZ.field.*.i)

  欠点  
    * 検索結果の表示が遅くなる
      (現在の NMZ.f に相当する情報を組み立てるのに複数の 
       NMZ.field.* を読む必要があるため)
    * ファイルがたくさん作られる (大したことじゃないけど)

NMZ.f + NMZ.fi に統合する方法

  利点
    * 検索結果の表示が高速 (今まで通り)
    * 作成するファイルが少ない (大したことじゃないけど)

  欠点  
    * フィールド指定の検索が遅くなる
      - 実質上、 NMZ.f 全体を read しなければならないため
    * 拡張性に乏しい
      - フィールドの追加、削除、更新はともに難しい

となります。どちらかといえば前者の方が好ましい気がするのです
が、いかがでしょう?


># 実際には、NMZ.f.info には、(要約に含める/含めない) (検索対象にする/し
># ない) といったフラグも記録することになるでしょう。

検索結果の表示をカスタマイズ可能にしようという考えもあって、
これは NMZ.result なりを用意し、

  <dt>
  <strong><a href="$uri">$title</a></strong>
  <dd>
  <strong>Author</strong>: <em>$author</em><br>
  <strong>Date</strong>: <em>$date</em><br>
  <strong>Size</strong>: <em>$size bytes<\em><br>
  $summary
  <dd><a href="$uri">$uri</a><br><br>

といった記述から、 $uri, $title, などの部分を検索結果の表示
の際に NMZ.field.* の内容を元に動的に置き換える、という仕組
みを考えています。

ただ、こういった処理を C言語で実現するのは面倒なのが難点です。
どなたか書きません? :)

-- Satoru Takabayashi
今日も試験、明日も試験