namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

knok@xxxxxxxxxxxxx (NOKUBI Takatsugu) wrote:

>> 試してみました。 make 一発で kakasi コマンドと libkakasi が
>> 作れるのはよいですね。が、どうせなら Perl の Text::Kakasi モ
>> ジュールも作れるようにパッケージングしません?
>
>  うう、ということはautomake/autoconfの使い方を覚えなければならないん
>ですね... できるだけそこは避けてきたのですが、ついに腹をくくらねばなら
>ない時期が来たようです ^^;

そのくらい野首さんなら朝飯前でしょう。 :)


>  せっかくなので、shared libraryを作成する部分もちゃんとconfigureから
>生成できるようにしたいと思います。現状ではGNU binutils以外を考慮してい
>ませんので。

よく知りませんが、 NDTPD では GNU の libtool なるツールを使っ
ていますね。


>> CVSの管理下に置いていいんじゃないでしょうか? ディレクトリ名
>> にヴァージョンがつくと面倒なので File-MMagic という名前で。
>> んで、基本的に野首さんが保守すると。
>
>  となると、手元にあるFile::MMagic用リポジトリとNamazuとでバージョン番
>号が違ってしまいますが、よくよく考えたらそんなに気にしなくてもいいよう
>に思えてきました。
>  では、こちらでの実装が進んだ段階でcommitすることにします。

よろしくお願いします。ところで、ソースを眺めていると、

                "text/rfc822" => [ "Received:",   
                             ">From",       
                             "Return-Path:",
                             "Cc:",         ],
                 "text/news" => [ "Newsgroups:", 
                             "Path:",       
                             "Organization:" ],

なるコードが見つかりましたが、この 2つは区別しないで 
text/rfc822 にまとめてしまえばいいんじゃないでしょうか?

あと、text/x-mhonarc, text/x-man, text/x-rfc,
application/x-bzip といったあたりの識別も行ってもらえると助
かります。 (x- は不要?)


>> 文書の読み込み部とフィルタ部は統合して見通しをよくしたいと思っ
>> ています。また、API を決めて新しいフィルタを追加しやすくした
>> いところです。
>
>  とりあえず、フィルタ部についてだけ考えてみました。
(snip)
>新案:
>・%HELPER_ACTIONSにて、Media Typeに対応する処理関数とを定義
>・%REQUIRE_ACTIONSにて、Media Typeに対応して呼び出すモジュール
>  (lib/*.pl)を定義

%HELPER_ACTIONS と %REQUIRE_ACTIONS 2つにわかれているとやや
こしいので、%REQUIRE_ACTIONS 1つだけでよい気がします。


>・@RECURSIVE_ACTIONSにて、再帰的に処理を行うMedia Typeを指定
>  (圧縮データなど)

確かにこういった仕掛けは必要ですね。(ハッシュの方がよいので
は?)

# .tar.gz を扱えると嬉しいかな? 検索結果は 
# /somewhere/foo.tar.gz#filename みたいな感じで出力する仕様
# にして。これができるなら HTML の <a name="foo"> にも対応で
# きると思う。 (実装はちと難しそうですが)


> %REQUIRE_ACTIONS = {
> 	'text/x-roff' => 'troff',
> 	'text/html' => 'html',
> 	'application/x-gzip' => 'gzip',
> 	'application/x-compress' => 'compress'
> };
 
これを見て気づいたのですが、各種文書形式に応じた読み込み・整
形処理は文書の種類ごとに一つのファイルにまとめるとよさそうで
す。

つまり、現在は lib/filter.pl というファイルに各種文書用の整
形処理がまとめられていますが、これらをすべて rfc.pl,
gzip.pl, mhonarc.pl, man.pl, html.pl, rfc822.pl (mail/news), 
と分割するわけです。そうすれば、新しい文書形式に対応するのが
簡単になります。

また、今までは文書の読み込み部と整形部 (前回のメイルでは整形
部をフィルタ部と呼んだが、まぎらわしいので言葉を変える) が分
かれていましたが、これらは統合して一つの処理にまとめた方がよ
いですね。タイトルの抽出、フィールド情報の抽出 (特に 
mail/news)、文字列の重みづけ、といった処理もこの部分で行いま
す。(これをを文書モジュールと呼ぶ)

# タイトルは $fields->{'title'} に、フィールド情報は 
# %fields, 文字列の重みづけは $weighted_str に記録する。

インターフェイスは各文書モジュール毎に read (ファイルを読み
込む) と format (テキストを整形する) というサブルーチンを定
義して、 mknmz からは

      for my $file (@target_files) {
           my $mm   = new File::MMagic;
           my $type = $mm->checktype_filename($file);
           my $content = read_document($file, $type);
              :
      }

  sub read_document($$$) {
      my ($file, $type) = @_;
  
      require "$LIBDIR/$REQUIRE_ACTIONS{$type}.pl";
  
      my $content = "";
      my $red  = 0;
  
      do {
          unless ($red) {
              $content = eval "$type::read(\$file)";
              $red = 1;
          }
          $content = eval "$type::format(\$content)";
      } while ($RECURSIVE_ACTIONS{$type})
  
      return $content;
  }

といった感じで処理すればよいかな。


>> 必要とあれば現在 lib ディレクトリの下にある *.pl のコードは
>> Perlモジュール化していきましょう。 (野首さん、助言をお願いし
>> ます)
>
>  とりあえずは、そこまで必要とはしないと思います。今後状況が代わって来
>るようであれば、その時考えましょう。

そうですね。


>  まあ、ものは試しということで実際にbranchを作ってやってみることにしま
>す。ひと段落するまで実装を続けてみて、これで不都合があるようなら次回か
>らは作らないようにすればいいわけですし。

よろしくお願いします。

-- Satoru Takabayashi