Namazu-devel-ja(旧)

[Yukio USUDA <usuda@xxxxxxxxxx>]

> At Thu, 17 Apr 2003 12:17:00 +0900,
> Yukio USUDA wrote:
> > 一つのメディアタイプに対して複数のテキスト化ツール、html化
> > ツールを選択できるようにした場合
> > 現在は、excel.pl,word.plなどではひとつのfilterモジュール内で
> > 判定し対応していますが、メンテナンスを考えると別々のモジュール
> > にしておいたほうがよいのではないでしょうか。

knok@xxxxxxxxxxxxx wrote:
>   確かにメンテナンス性は良くなりそうですね。おっしゃる通り、動作上もお
> そらくは問題ないと思います。

モジュールをばらばらにしておけば
mknmz -C の表示に
メディアタイプ毎で使用されるモジュール名も表示するようにしておけば
実際に使用したフィルタツールと一対一で対応するので動作checkがしやすい
だろうと思っています。
現在はmake checkをしても実際にはfilterについては一部のモジュールやサブ
ルーチンしか動いていないのとどれが動いたのかlogに残らないのでなんとなく
不安です。

> > Perlはガベージコレクションをしてくれるものと思うのですが。
>   バイトコードとしては使われなくとも保持されたままになると思うので、別
> パッケージとして同じようなコードを複数持つ方がおそらくメモリを消費する
> のではないかと思います。
不要なデータは掃除されても不要なコードまでは掃除されないということですね、
モジュールの使用優先順位を明示する仕組みもあればいいのかなと思っているの
ですが読み込みを抑制する仕組みもなければメモリ消費上は意味がないですね

>   まあでも私はそれでもメンテンス性が上がる方が良いように思います。逆に
> 言えば不要なフィルタをファイルごと消せばその分使用メモリも減らせるわけ
> ですし。
追加のコードは不要だし、用意する側では楽ですね。
それぞれのモジュールについて説明があれば、消すだけなら単純でわかりやす
いのかもしれません。なんとなく安直な気もしますが、本当にこれでよければ
今後の作業指針にします。

また、過去のメールログを読んでいたところ既に同様の提案がありました。
http://www.namazu.org/ml/namazu-devel-ja/msg01403.html
以前に比べるとdoccatは非常に高価になっています
既存モジュールを触ると後で動作検証できないのも気になっています。

HEADの方では
このメールで提案されているdoccat.plの形で切り離したら後々扱いやすいだろう
と思いますが、乱暴でしょうか？

臼田幸生