> 実は現在のtokenizerはUCS2をUTF8に変換し、strtokで分解しています。やめてくれー。
> で、マルチバイト文字が出てきたらそれをUCS2に変換してi18n scannerで分解し、さらにUTF8に変換して辞書に載せるという…。やめてくれー。
なんか複雑そうですね、さっぱりわかりません　(^^;)
それって、microsoftの関数を使いたくないからなんでしょうか


> これは問題にはならなさそうですね。MIMEデコードのオーバーヘッドなんてのはたかが知れてるので。ほとんどの場合、メール一通につき一回通るだけでしょうし。
まぁ、from:、To:、Subject: ぐらいですかね


> これはやっぱり、トークンの賞味期限を設定する必要がありますね。
> ヘッダも何も、区別せずに全部受け入れて、使われなくなった古いのは捨てる、というアプローチは単純でエレガントだと思います。
これはどこかに書いてあった 登録日付と最終参照日なども辞書に置いておく方式でしょうか。ヘッダと本文を区別しないっていうのは良い感じがします。


> > また、メッセージフィルタの方と自然に連携できる仕組みも必要だと思います。（今は一発で出来ない）
>
> 連携というのは具体的にどういう機能でしょうか。
> メッセージフィルタで分類して、同時にジャンク・非ジャンクに学習させるとか？
そうですね、
現状はメッセージフィルタでジャンクフラグは立てることは出来るんです。しかし、ジャンクフィルタが処理できるタイミングではなくなるので、ジャンクメールボックスに移動させたい設定にしていても移動できないんです。（mailnews.ui.junk.firstuseの設定で実行タイミングを変えられますが弊害も多い。"メッセージフィルタの前と後両方で実行"っていうのが有れば．．．）
メッセージフィルタでジャンクフラグを立てたときにはtraining.datに登録してほしいんです。
（やっているのかもしれないけど、そうは見えない）

メッセージフィルタで処理してジャンク扱いしたときは、メッセージフィルタの条件に指定した項目をトークンとして登録されるようになれば良いのかな。
＃ こういう機能を追加すればトークンを制御出来るような気がします　（非ジャンク扱いも）


> 個人的には、ジャンク・非ジャンクの学習数はなるべく少ないほうがうまく動くような気がしています。数よりも、種類が大事なのかな。いろいろ学習させる。
> 初期に少数のメールで学習した後、失敗したやつだけ再学習させていく程度のほうが、最終的にはうまくいくような気がします。
私もそういう気がしています。結局２ＭＢ程度の小さなtraining.datでうまく行っているんです。


> 辞書に単語を登録するインタフェイス、メッセージのトークン化を依頼するインタフェイスを露出させておいて、JavaScript側でトークン分離の処理をするという。
> でも、XPCOMインタフェイスの書き方がよく判らないのと、Javascriptでは満足な速度が得られないであろうこと、色々選択肢があっても最終的に必要なのはベストの一つになるはず、と思ったので、これは断念しました。
extension本体はc++で書いて なんでも出来るんじゃないんでしょうか。（って、言うだけなんですけど　(^^;)
私はextensionにはまってしまうと危なそうなので近寄りませんが、性能を競う人も出てきたりすると結果的に良いものが残るんですよね。まずは環境を提供してほしいってところでしょうか。
extension自体はソースがオープンになっているものも有るので参考に出来るのかな。でもEnigmailのソースは読めませんでした。
＃ 私は「c」の一部分しかわかりません　(^^;)