Namazu-devel-ja(旧)

[Yukio USUDA <usuda@xxxxxxxxxx>]

臼田です。

knok wrote:
>   本当は、内部で処理されるデータに言語情報をもたせ、
> * 読み込み処理の範疇で言語/encoding が判明した場合
> * filter 処理で判明した場合
>   それぞれに対応できるようにするのが良いのかな、という気がしています。
>  前者はたとえば、HTTP で取得したときに得られる charset パラメータが該
> 当するでしょうし、後者は HTML 内に記述されている meta tag の内容で決定
> される場合が一例となるでしょう。

httpのcharsetパラメータ,metatag,拡張子情報などを信頼するか、
しないかのレベルを設定できるようにすれば、文字コード判定処
理、mmagic処理等の省略が柔軟に選べてユーザーに速度と識別
精度での選択肢が与えられますね。

2.0→2.1でmknmz内の見通しを少しづつ良くしていることと
2.1ではAPIの変更を厭わないということなので考えていることを
もう少し書いておきます。

Documentのオブジェクトを作って

$content : 読み込まれたデータの塊
$state : データの状態
      （'undef','binary','archived','impure_text','plaintext',etc..)
$normalize : 正規化状態
       （'notyet','normalized',etc..)
$wakatize : わかち状態
       （'unneccesary','notyet','wakatized',etc..)
$charactercoding : ('undef','euc','utf-8','unknown',etc..)
$orig_mimetype : ('undef','text/plain',etc...)
$uri : 'file://hogehoge.txt'、'http://foo.net/index.html#bar'等
%fields : 作者名、キーワード、作成日等々をハッシュで持たせる。

といった情報をまとめた構造体で渡すことにして引数を整理しては
どうかと思います。
各モジュールでの処理結果をラベル付けしなおして持ち歩くように
することで処理済みの処理を再度施すのを避けられるかと思います。

あるいはいっそのことnamazucoreの部分を変えてしまって
オブジェクト自身に自分の状態を責任を持って管理させればよいのか
もしれません。

$doc = Document->new();
$doc->loadcontent($uri);
$doc->mmagic();
$doc->filtering();
$doc->codeconv_from_to($charactercoding,$index_coding);
$doc->normalize_jp_code();
$doc->wakatize();
$summary = $doc->get_summary();
$wakatizeddoc = $doc->get_wakatizeddoc();
$doc_author =  $doc->get_authorname();
$filename = $doc->get_filename();
etc...

filterをmknmz以外のスクリプトからも利用しやすい形にするには
どうしたらよいかをここしばらく考えているところです。
Perlでのオブジェクト指向プログラミングはどうも不自然に見えて
試みたことがないので詳しい方のご意見が欲しいです。

圧縮ファイルやhtmlsplit等の再起的に動くフィルタがあるので
オブジェクトはどこで生成するべきか、データの状態としてどのよ
うな情報を持つべきか、むずかしいですね。

臼田幸生