DisplayName[改行][TAB]<mail@address>のDNo.09186
ポン太 さん　05/04/08 15:05
　
秀まるお さん、こんにちは。ポン太 です。
Thunderbird の重さに耐えられなくなって、GDS Plugin for 鶴亀メール を作成
しています。(^_^; SDK で公開されている部分の実装はほとんどできてます。

その時に hidesoft.8 のメールで気になったのですが、hidesoft.8 のメールの
From: は表題の通りになっています。これを鶴亀メールは
DisplayName<mail@address> とします。Thunderbird は
DisplayName <mail@address> となります。
後者の方がより一般的ではないでしょうか？

どちらも間違いではないということでしたら、後者の方にしていただいたらあり
がたいです。


2005/04/08(金) 14:39　ポン太
[ △ ]
RE:09186 DisplayName[改行][TAB]<mail@adNo.09187
秀まるお さん　05/04/08 17:48
　
　鶴亀メールでのこの辺の実装は、たしかOutlook Expressを参考にしてたと思
います。たしか昔この辺をいろいろ調べた時に、メールソフトによってまちまち
だったので、無難な方向ってことでOutlook Express互換にした覚えがあります。

　ただ、たしかにご指摘の通り、From:ヘッダやTo:ヘッダなどでの

　「名前 <Email>」

　の形式の場合は、たしかに名前の後ろに空白が１個あった方がいいです。

　というか、実はそもそもFrom:ヘッダやTo:ヘッダは鶴亀メール側で既に勝手に
整形するような処理なんかも既に入っていますので、それを改良する方向で実現
可能です。

　ってことでそううい風にするつもりで、ソースコードを追っかけるなどしてみ
ます。

　あと、Google Desktop Search用のプラグインを作成されてるそうで、なんと
言っていいか分かりませんが、とりあえずありがとうございます。鶴亀メールの
検索を高速化する方もぼちぼちやろうかなぁと思いつつ、やるとなれば、メール
一覧のキャッシュ（list.bin）に改良が必要でしてまだ保留しています。
[ △ ]
RE:09187 DisplayName[改行][TAB]<mail@adNo.09188
ポン太 さん　05/04/08 18:58
　
秀まるお さん、こんにちは。ポン太 です。

>　ってことでそううい風にするつもりで、ソースコードを追っかけるなどしてみ
>ます。

よろしくお願いします。

>　あと、Google Desktop Search用のプラグインを作成されてるそうで、なんと
>言っていいか分かりませんが、とりあえずありがとうございます。鶴亀メールの

とりあえず自分が必要な物がなければ作っちまう性格なもので。(^_^;
ただし公開するかどうかはまた別問題（今のところ未定）です。私としては純正
を今でも期待しています。


作ってみてはっきりしましたが、GDSへの登録は鶴亀メール本体（あるいはマク
ロ）がやるのが一番効率が良いです。

通常GDSへプラグインを登録するときに、特定の拡張子を登録することでGDSから
その拡張子のファイルに変更があったときに、プラグインの自作の機能が呼び出
され、その処理の中でメールをGDSに登録することになります。
この方法だと鶴亀メールのメールファイルの場合、途中のメールが消えたりする
関係上、どうしてもファイル全体をなめて、登録済みのメールかどうか判断する
という無駄な処理が必要になります。
鶴亀メール本体が処理する場合なら、直近の受信したメールを特定するのが簡単
なので、GDSへのメールの登録が圧倒的に楽になるはずです。GDSへのメールの登
録は、GDSから呼ばれた関数でやらなくてはならないわけではなく、普通のアプ
リから簡単に行えます。GDSへ登録するためのダミーのインプロセスサーバーを
作成する必要はありますが。

マクロのSelectRecvMailで選択して、メールを（ヘッダを含めて）GDS用のDLLへ
渡すというマクロ（受信が一段落した時に起動）も考えたのですが、大量に受信
したときに現在のマクロの仕様だとレスポンスに問題が出そうであきらめました。

ということで鶴亀本体での対応が理想ですが、それが無理ならマクロを拡張して
いただけないでしょうか。
希望は（RecvMailCountとSentMailCountは既にあるので）、直前の送受信で送受
信したメールを返す関数です。SelectRecvMailしてgofiletopして、等とやらず
に済むようなやつです。ヘッダと本文を同時でも良いですし、ヘッダのみ本文の
みと分かれていても良いです。

構文はでたらめですが、
for i:=0 to RecvMailCount-1 do begin
  $n = dllfuncstr("RecvMailByNumber", i);
  自作dllの呼び出し($n);
end;
for i:=0 to SentMailCount-1 do begin
  $n = dllfuncstr("SentMailByNumber", i);
  自作dllの呼び出し($n);
end;
みたいなやつです。

よろしくお願いします。


2005/04/08(金) 18:18　ポン太
[ △ ]
RE:09188 DisplayName[改行][TAB]<mail@adNo.09191
ポン太 さん　05/04/09 10:55
　
秀まるお さん、こんにちは。ポン太 です。
補足と追加です。


>希望は（RecvMailCountとSentMailCountは既にあるので）、直前の送受信で送受
>信したメールを返す関数です。SelectRecvMailしてgofiletopして、等とやらず
>に済むようなやつです。ヘッダと本文を同時でも良いですし、ヘッダのみ本文の
>みと分かれていても良いです。

直前の送受信で送受信したメールを返す関数とは、メールを選択・開く・範囲選
択等をしなくても、番号を指定するだけでメールの中身（ヘッダと本文）を文字
列として返してくれる関数という意味です。

それから同様に番号指定だけで、アカウントとフォルダ名を返していただけると
完璧です。一応GDSにメールを登録するときに、フォルダ名を設定でき、検索結
果にそのフォルダ名が表示されるので。


2005/04/09(土) 10:49　ポン太

p.s.
でも理想は鶴亀本体でGDSに登録してくれることです。(^_^;
[ △ ]
RE:09187 DisplayName[改行][TAB]<mail@adNo.09192
cuma さん　05/04/09 23:33
　
秀まるお様、ポン太様、こんばんは

　cumaです。

>　あと、Google Desktop Search用のプラグインを作成されてるそうで、なんと
>言っていいか分かりませんが、とりあえずありがとうございます。鶴亀メールの
>検索を高速化する方もぼちぼちやろうかなぁと思いつつ、やるとなれば、メール
>一覧のキャッシュ（list.bin）に改良が必要でしてまだ保留しています。

久しぶりに拝見していたら鶴亀本体の検索の高速化もGDSの対応も進んでいるみ
たいでうれしくなりました。
[ △ ]
RE:09191 DisplayName[改行][TAB]<mail@adNo.09194
秀まるお さん　05/04/10 20:32
　
　いっそのこと、そのポン太さんの作成されたプログラムを僕が買い取って、サ
イトー企画からちゃんとしたサポート保障付きで提供するという手もありますが、
そういうのはどうでしょ？

　（C++言語で書かれてるという前提での話ですが）

　いくらくらいで売ってくれるかによりますけど。
[ △ ]
RE:09194 DisplayName[改行][TAB]<mail@adNo.09197
秀まるお さん　05/04/11 08:18
　
　話を理解してなかったので今さらGDSのSDKドキュメントを見始めたんですが、
つまり、ポン太さんの作成されたプラグインというのは、例えば鶴亀メールの
データ形式専用の特定拡張子を定義して、その拡張子に対応したプラグインを作
成されたって話ですね。

　でもそれでは効率が悪いから、鶴亀本体が（主導的になって？）GDSにメール
データの位置などを渡してやるような仕組みにすべきとかなんとか…。

　もうちょっとSDKを読んでからお返事します。
[ △ ]
RE:09197 DisplayName[改行][TAB]<mail@adNo.09198
ポン太 さん　05/04/11 09:33
　
秀まるお さん、こんにちは。ポン太 です。

私の作ったGDS用のソフトのソースは、必要であればいつでも無償でお送りしま
す。ただしDelphiのソースです。ですが、ソースのほとんどは鶴亀のメールファ
イルを監視したり、メール毎にばらしたりする部分で、肝心のGDSに登録する部
分はほんの数行なので、まるお さんが少しSDKのドキュメントと、サンプルを見
ていただければ何のことはないプログラムだと思います。


>　話を理解してなかったので今さらGDSのSDKドキュメントを見始めたんですが、
>つまり、ポン太さんの作成されたプラグインというのは、例えば鶴亀メールの
>データ形式専用の特定拡張子を定義して、その拡張子に対応したプラグインを作
>成されたって話ですね。

拡張子登録はしていませんが（鶴亀はユーザーが拡張子変更可能なので、鶴亀の
データフォルダをFindFirstChangeNotificationで監視しています）、概ねそう
いうことです。


>　でもそれでは効率が悪いから、鶴亀本体が（主導的になって？）GDSにメール
>データの位置などを渡してやるような仕組みにすべきとかなんとか…。

まさにそうです。
あっ、ですがメールのデータ位置を渡す部分のAPI（あるいは登録したメールか
ら別アプリを起動する方法、「Thunderbirdで表示」に相当する機能）は、まだ
（おそらく）公開されていないようですから、今のところは
var
  IGDSE:IGoogleDesktopSearchEvent;
begin
  GoogleDesktopSearch:=TGoogleDesktopSearch.Create(nil);
  try
    IGDSE:=GoogleDesktopSearch.CreateEvent(GDS_TK_GUID,'Google.Desktop.
Email') as IGoogleDesktopSearchEvent;
    IGDSE.AddProperty('content',Body.Text);
    IGDSE.AddProperty('received',ADate);
    IGDSE.AddProperty('format','text/plain');
    IGDSE.AddProperty('mail_header',Header.Text);
    IGDSE.AddProperty('folder_name',FolderName);
    IGDSE.Send(1);
  finally
    GoogleDesktopSearch.Free;
  end;
など（省略したDelphiソースですが）と、メールのヘッダ、受信日時（標準時）、
本文、フォルダ名を渡して登録することしかできません。


>　もうちょっとSDKを読んでからお返事します。

まるお さんなら必要ないでしょうが、もし手抜きしたいなどの理由で必要があ
れば、ポイントをサンプル(C,C#)から抜き出してメールさせていただきます。

よろしくお願いします。


2005/04/11(月) 09:14　ポン太
[ △ ]
RE:09198 DisplayName[改行][TAB]<mail@adNo.09199
ポン太 さん　05/04/11 10:03
　
秀まるお さん、こんにちは。ポン太 です。

>あっ、ですがメールのデータ位置を渡す部分のAPI（あるいは登録したメールか
>ら別アプリを起動する方法、「Thunderbirdで表示」に相当する機能）は、まだ
>（おそらく）公開されていないようですから、今のところは

補足すると、一度登録したメールを削除する方法も、今のところ公開されていな
い（はずな）ので、現在はメール登録することしかできません。いずれ公開され
てくるとは思いますが。
従ってやること、やれることはほとんどないので、逆に非常に簡単です。


2005/04/11(月) 09:56　ポン太
[ △ ]
RE:09199 DisplayName[改行][TAB]<mail@adNo.09200
秀まるお さん　05/04/11 10:29
　
　一応、状況が理解できたと思います。しいてgoogle desktop search用のプラ
グインを用意しなくとも、鶴亀メールから能動的に、その

　CreateEventして
　AddPropertyして
　Send

　って処理を、とにかく受信したメールについて毎回実行してやればいいだけな
んですね。さらには、既存のメールについてGDSに渡してやるような機能も用意
してやればいい訳で…。

　GDS用のプラグインを作るのは後回しにして、とりあえずそういう、鶴亀用の
拡張DLLを作るってことで挑戦してみます。迷惑メールフィルターの仕組みを少
しいじれば、たぶん簡単に実現できると思います。
[ △ ]
RE:09200 DisplayName[改行][TAB]<mail@adNo.09202
ポン太 さん　05/04/11 12:00
　
秀まるお さん、こんにちは。ポン太 です。

>　一応、状況が理解できたと思います。しいてgoogle desktop search用のプラ
>グインを用意しなくとも、鶴亀メールから能動的に、その
>
>　CreateEventして
>　AddPropertyして
>　Send
>
>　って処理を、とにかく受信したメールについて毎回実行してやればいいだけな
>んですね。さらには、既存のメールについてGDSに渡してやるような機能も用意
>してやればいい訳で…。

概ねそうです（受信したメールだけではなく送信済みもオプションか何かで）。
ただダミーのプラグイン（インプロセスサーバーというかActive-X DLLという
か）を作って、GDSに登録しないといけないです。登録されると以下のURLのよう
な感じになります。
http://homepage3.nifty.com/yutaro/GDS_plugin.jpg
でそのDLLのGUIDをCreateEventの最初の引数にする必要があります。
また上記URLの図でチェックをはずされる場合があり、その場合はCreateEventで
エラーが帰ってきます。

ちなみにインプロセスサーバーをGDSに登録するのはこんな感じです。
１．DllRegisterServerを呼んでインプロセスサーバーのWindowsへの登録。
２．（またDelphiのコードですが）
var
  Desc:OleVariant;
  GoogleDesktopSearchRegister:TGoogleDesktopSearchRegister;
  RegExt:IGoogleDesktopSearchComponentRegistration;
begin
  GoogleDesktopSearchRegister:=TGoogleDesktopSearchRegister.Create(nil);
  try
    Desc:=VarArrayCreate([0,5], varVariant);
    Desc[0]:='Title';
    Desc[1]:='鶴亀メール';
    Desc[2]:='Description';
    Desc[3]:='鶴亀メールのIndexing';
    Desc[4]:='Icon';
    Desc[5]:='';
    RegExt:=GoogleDesktopSearchRegister.RegisterComponent(GDS_TK_GUID,
Desc);
  finally
    GoogleDesktopSearchRegister.Free;
  end;

>　GDS用のプラグインを作るのは後回しにして、とりあえずそういう、鶴亀用の
>拡張DLLを作るってことで挑戦してみます。迷惑メールフィルターの仕組みを少

というか、上記ダミーのインプロセスサーバーと鶴亀用の拡張DLLを合わせて、
GDS用のプラグインと呼んで良いと思います。サンプルの中にはIndexを登録する
exeもありますし（私のアプリもexe形式です）。


>しいじれば、たぶん簡単に実現できると思います。

すごく期待しています。(^^)
よろしくお願いします。


2005/04/11(月) 11:37　ポン太
[ △ ]
RE:09202 DisplayName[改行][TAB]<mail@adNo.09205
秀まるお さん　05/04/12 20:59
　
　DLL作ってみまして、一応それなりに動くようになりました。

　鶴亀メールから能動的にメールをお知らせする、つまり、自分から能動的に
CreateEventしてAddPropertyしてSendしてってことも出来るようにしてみました。
しかし、残念ながら、それを呼んだ直後にDesktop検索しても、登録されたはず
のメールはヒットしてくれません。

　しばらくマシンをアイドル状態にしてから検索すると、ヒットするようになり
ます。

　ということで、つまり、鶴亀メールが能動的にやってもあんまり意味が無くて、
結局はGoogle Desktop Search側から自分自身のHandleFileメソッドを呼んでく
れるまで待った方がいいような気がします。

　そういうことでいいですかね？。

　つまり、鶴亀メールとしてやることは、

　１．鶴亀メールのメールデータ用の拡張子を何か１つ決める。
　　　（とりあえず「tkeml」にするつもり）

　２．鶴亀メール側に、例えば「全般的な設定・上級者向け・デスクトップ
　　　検索」のような設定ページを用意して、そこで、

　　　□ Google Desktop Search用に、メールデータの拡張子を「.tkeml」に
　　　統一する

　　　みたいなオプションを用して、それをONにしたら、既存のメールデータ
　　　も含めて全部のメールデータのファイル拡張子が自動的に「.tkeml」に
　　　なる物とする。

　３．Google Desktop Search用の鶴亀メールのプラグインは、それはそれで
　　　鶴亀メールに付属させるなどして配布しつつ、それもその「全般的な
　　　設定」から登録（regsvr32）できるようにする。

　っと、そういうことになろうかと思いますが…。

　だいたいそういう方向でいいですね？

　ちなみに作成途中のDLLは、

http://pub.idisk-just.com/fview/U6pze7riTvAeDVOBAVuWEX7OnSc954PDAKheilAlm_Cg
OYs7bXLRUZNT81Xyt0NPxsXqblilbEY.lzh

　からダウンロードできます。regsvr32すると使えます。

　c:\TuruKameGDS_dump.txtというファイルに活動状況を出力するような動作に
なっています。あと、外国語メールではまだ一切テストしてません。

    loaddll "e:\\usr95\\turukamegds\\debug\\turukamegds.dll";
    #n = dllfunc("DoIndexing", "c:\\temp.txt");

　みたいなマクロを使って能動的に登録させるテストも出来ます。
[ △ ]
RE:09205 DisplayName[改行][TAB]<mail@adNo.09206
秀まるお さん　05/04/12 21:45
　
　僕の作ったプラグインをregsvr32しておくと、メール用のファイルの拡張子を
「.txt」から「.tkeml」に変更したとたんに、プラグインがばしばし呼び出され
てしまうようです。手元のメール用ファイルを１０個ほど拡張子変更しただけで
も、今、マシンがとんでもなく重くなってます。

　で、その重いのは別にして、どっちにしても、メール用のファイルが書き換え
られると、こうやって自動的にプラグインが呼び出されまくってしまうようです。
なので、さらに能動的にどうこうする必要は無いと思います。

　しいて能動的にやったら二重登録になるだけのような気がします。
[ △ ]
RE:09206 DisplayName[改行][TAB]<mail@adNo.09207
ポン太 さん　05/04/12 23:07
　
秀まるお さん、こんにちは。ポン太 です。

>　しいて能動的にやったら二重登録になるだけのような気がします。

まだ良くコメントを読んでないのですが、意見を言っておかないと突っ走られる
ような気がして(^_^;、とりあえずコメントします。

HandleFileの中身が分からないのであれですが、例えば（極論ですが）、
今100万通のメールが入っている一つの100MBの「.txt」ファイルがあります。こ
れを「.tkeml」へ変更されるとHandleFileが呼ばれ、100万通がGDSへ登録されま
す（よね？）。
で、1通のメールを受信します。またHandleFileが呼ばれ、100MB+1通の「.
tkeml」がHandleFileされますよね。そうするとこのときのHandleFileの動作と
しては、100万+1通のメールが登録済みかどうか、「.tkeml」をなめていって登
録していない1通の時だけGDSへ登録します。
で、次の1通を受信しても再度100MBをなめることにはなりませんか？

能動的にやって欲しいのは、GDSですぐに検索できるという考えからでは全くな
く（すぐには検索できなことがあるのは確認済みです）、100MBのファイルを何
度もなめることになるのが無駄だと思ったからです。

もしかしたら「.tkeml」は1メール1ファイルのつもりですか？もしそうならそれ
はディスクの無駄づかいになるでしょうから反対です。

私がダミーのDLLと言ったのは、HandleFileで何も動作しない・拡張子登録も行
わないDLLというつもりだったのですが。登録はHandleFileでやるのではなく、
鶴亀が受信したメールごとにやるということです（過去メールは一括登録の仕組
みが必要ですが）。


2005/04/12(火) 22:51　ポン太
[ △ ]
RE:09205 DisplayName[改行][TAB]<mail@adNo.09208
ポン太 さん　05/04/13 01:09
　
秀まるお さん、こんにちは。ポン太 です。


>　ちなみに作成途中のDLLは、
>
>http://pub.idisk-just.com/fview/U6pze7riTvAeDVOBAVuWEX7OnSc954PDAKheilAlm_Cg
>OYs7bXLRUZNT81Xyt0NPxsXqblilbEY.lzh
>
>　からダウンロードできます。regsvr32すると使えます。

regsvr32 -i 鶴亀のインストールパス\TuruKameGDS.dll
とやったら、
---------------------------
RegSvr32
---------------------------
鶴亀のインストールパス\TuruKameGDS.dll は読み込まれましたが、DllInstall
エントリ ポイントが見つかりませんでした。

このファイルが登録されていない可能性があります。
---------------------------
OK  
---------------------------
と出ました(WinXP Pro SP1)。
とりあえず動作はしているようです。

あと日付は
! r:0 f:0 u:0 t:2005040821532429
をとっているのですね？サンダーバードの場合はDateヘッダをとっているみたい
です。
t:2005040821532429を採用しているにしても、9時間ずれていませんか？


作成途中だからということなら無視して下さい。


2005/04/13(水) 00:58　ポン太
[ △ ]
RE:09207 DisplayName[改行][TAB]<mail@adNo.09209
秀まるお さん　05/04/13 08:17
　
　今まさに、メールを受信しおわった後で、GoogleDesktopInってプロセスが
ハードディスクをアクセスしまくってまして、激重状態なんですけど、これを改
善するには、つまり、メール用ファイル全体をなめまわしてGDSへの登録をしま
くる仕組みを改めて、追加されたメールについてだけGDSへ登録しないといけな
いって話なんですかね。

　まぁ、それはそうとしても、ファイルが更新されたらされたで、GDSは必ず
プラグインなり、仮に「.txt」のままだとしても、それはそれで
テキストファイルとしてIndexingしようとするから、重くなることに変わりない
気もします。

　重くしないためには、つまり、.tkeml形式からHandleFileされてもそれは無視
してしまい、鶴亀メールが受信したメールについてだけGDSへ登録するような仕
組みにすればいいんですかね。

　そういうことでいろいろ試行錯誤してみます。

> regsvr32 -i 鶴亀のインストールパス\TuruKameGDS.dll
> とやったら、

　-iオプションはいらないです。DllInstallエントリーポイントは用意してない
です。（一応、サンプルもそうなっていたので）

> あと日付は
> ! r:0 f:0 u:0 t:2005040821532429
> をとっているのですね？サンダーバードの場合はDateヘッダをとっているみたい
> です。

　SDKの説明には「受信した時刻」のように書いてあったので、あえてそうして
います。一応意味的にはそれで合ってると思います。

> t:2005040821532429を採用しているにしても、9時間ずれていませんか？

　9時間ずれているのは、とりあえず動けばいいやってことでLocalTimeなのか
GMTなのか調べも確認もしてなかったせいです。ぼちぼち修正させていただきま
す。
[ △ ]
RE:09209 DisplayName[改行][TAB]<mail@adNo.09210
ポン太 さん　05/04/13 10:53
　
秀まるお さん、こんにちは。ポン太 です。

>善するには、つまり、メール用ファイル全体をなめまわしてGDSへの登録をしま
>くる仕組みを改めて、追加されたメールについてだけGDSへ登録しないといけな
>いって話なんですかね。

です、です。


>　重くしないためには、つまり、.tkeml形式からHandleFileされてもそれは無視
>してしまい、鶴亀メールが受信したメールについてだけGDSへ登録するような仕
>組みにすればいいんですかね。

それが親切なんでしょうね。
私は単純にGDSの設定で、検索しないアイテムに鶴亀メールのデータパスをユー
ザーに追加してもらえば良いと思っていましたが。


>　そういうことでいろいろ試行錯誤してみます。

よろしくお願いします。


>　-iオプションはいらないです。DllInstallエントリーポイントは用意してない
>です。（一応、サンプルもそうなっていたので）

了解です。


>　SDKの説明には「受信した時刻」のように書いてあったので、あえてそうして
>います。一応意味的にはそれで合ってると思います。

SDKの解釈は別にして、現状だとユーザーから「鶴亀で表示される日時とGDSの検
索結果の日時が違うんですがどうしてでしょう？」という問い合わせが続出して、
邪魔くさくなりませんかね？(^_^;

ちなみに私はReceivedを使うんだと思って（解釈して）そうやってみたのですが、
Thunderbirdと結果が違うので、Dateがある時はDate、Dateがないときは
Receivedの一番上を使うようにしています。


>　9時間ずれているのは、とりあえず動けばいいやってことでLocalTimeなのか
>GMTなのか調べも確認もしてなかったせいです。ぼちぼち修正させていただきま
>す。

了解です。

それから鶴亀のデータをコピーしてからしか試していないので、正規のデータの
場合はそうなっているかもしれませんが。
AddPropertyで渡している folder_name は現状ファイルのOS上のフォルダ名にな
っていませんか？これは鶴亀上でのアカウント名＋フォルダ名にした方が親切と
いうか分かりやすいと思いますが、如何でしょうか。


いろいろとありがとうございます。とても楽しみにしています。


2005/04/13(水) 10:39　ポン太
[ △ ]
RE:09210 DisplayName[改行][TAB]<mail@adNo.09211
秀まるお さん　05/04/13 21:23
　
　一応いろいろ苦労して、受信したメールがGoogleDesktopにIndexingされる所
まで行き着きました。

　.tkemlって拡張子でHandleFileさせる処理は凍結しました。

　既存のファイルを、GDS側からのHandleFileメソッド呼び出されによって
Indexingさせた場合は、そのファイルが無くなるとIndexingされたキャッシュも
自動的に消えてくれます。しかし、鶴亀メールが能動的に登録したメールについ
ては、たとえそのメールが削除されてもIndexingは残ってしまうようです。

　これはこれで予想された動作ですけど。仮に.tkeml形式ファイルから
HandleFileさせた場合は自動で消えてくれる訳で、それと比べるとデメリットに
なるような気もします。

　はて、これでいいんでしょうか。やっぱり、.tkeml形式ファイルにてGDSから
HandleFileさせる方式も残しておいた方が良かったかなぁなんて思ったりもしま
す。

---------------------
　Outlook Express上のメールがGDSにIndexingされたのもあるんですが、こちら
も同じく、Outlook Express上で削除されてもIndexingされたキャッシュは消え
ないようです。しばらくパソコンを放置しても消えないので、そういう物みたい
です。

　ということは、これはこれでGDSの仕組みってことで、現状の鶴亀メールの動
作でいいような気もしてきました。
[ △ ]
RE:09211 DisplayName[改行][TAB]<mail@adNo.09212
ポン太 さん　05/04/13 21:57
　
秀まるお さん、こんにちは。ポン太 です。

>　一応いろいろ苦労して、受信したメールがGoogleDesktopにIndexingされる所
>まで行き着きました。

お疲れ様です。ありがとうございます。m(_ _)m


>　これはこれで予想された動作ですけど。仮に.tkeml形式ファイルから
>HandleFileさせた場合は自動で消えてくれる訳で、それと比べるとデメリットに
>なるような気もします。
>
>　はて、これでいいんでしょうか。やっぱり、.tkeml形式ファイルにてGDSから
>HandleFileさせる方式も残しておいた方が良かったかなぁなんて思ったりもしま
>す。

う〜ん、なんともいえないですね。これからのSDKの充実次第でしょうが。
私としてはGDSで検索した結果から、鶴亀が起動するのが理想なのですが、それ
もこれからのSDK次第ですからね。


>　ということは、これはこれでGDSの仕組みってことで、現状の鶴亀メールの動
>作でいいような気もしてきました。

良いんじゃないでしょうか。私は全然ＯＫです。
βで良いので早く公開をお願いします。m(_ _)m


2005/04/13(水) 21:53　ポン太
[ △ ]
RE:09211 DisplayName[改行][TAB]<mail@adNo.09214
ポン太 さん　05/04/14 09:00
　
秀まるお さん、こんにちは。ポン太 です。


>　既存のファイルを、GDS側からのHandleFileメソッド呼び出されによって
>Indexingさせた場合は、そのファイルが無くなるとIndexingされたキャッシュも
>自動的に消えてくれます。しかし、鶴亀メールが能動的に登録したメールについ
>ては、たとえそのメールが削除されてもIndexingは残ってしまうようです。

この件ですが、まるお さんのHandleFileの中身は、.tkemlファイルを1メール毎
にばらして、AddPropertyしてSendするっていう処理だけですよね？登録済みか
どうかは判断せずに。GDS側にはこのHandleFileの中身は分からないはずなので、
メールが削除されてIndexが消えるというのは、.tkemlファイルが更新されると
一旦前回登録したIndexをGDSがすべて削除して、改めてHandleFileで現在の.
tkemlがすべて登録され直すということになりますよね。
それじゃPCが激重になるはずですね。(^_^;
メールのデータの場合1メール1ファイルじゃないと、HandleFileの処理では激重
になるのは避けられそうにないですね。


>　これはこれで予想された動作ですけど。仮に.tkeml形式ファイルから
>HandleFileさせた場合は自動で消えてくれる訳で、それと比べるとデメリットに
>なるような気もします。

デメリットではあるでしょうが、ファイルが更新されたときの処理が上記予想通
りだとすると、致し方ないでしょうね。
まぁ、spamなどが登録されてGDSでの検索で偶然引っかかってきたら、ユーザー
がGDSの画面（ブラウザ）で削除すれば良いだけですし。


2005/04/14(木) 08:48　ポン太
[ △ ]
RE:09214 DisplayName[改行][TAB]<mail@adNo.09215
秀まるお さん　05/04/14 11:49
　
　HandleFileでの処理はその通りです。渡されたファイル中に含まれるメールす
べてをAddProperty/Sendするだけです。

　で、その処理は封印して、今は鶴亀メールから能動的に呼ばれてAddProperty/
Sendしています。でもやはり、受信した後にはマシンがとんでもなく重くなりま
す。鶴亀からのAddProperty/Sendは一瞬で終わるんですが、後々になってGDSが
実際の処理を始めると重くなって、GDSのインデックスステータスを見ていても、
メール１通処理するのにかなり時間をかけてやってる様子が分かります。

　あと、僕が思うに、以前AddProperty/Sendしたことがあるメールとまったく同
じメールをもう一度AddProperty/Sendしても、それはそれで無視されるような気
がします。だとしたら、「.tkeml」形式にしつつHandleFileメソッドで処理して
も、大して遅くならない気がします。一番遅いのはGDS側のインデックス作成処
理でして、鶴亀側がメール用ファイルをAddProperty/Sendする重さよりもそっち
の方がはるかに重いですので。

　っと言いつつも、とりあえず現段階でちゃんと動くようになったらβ版を
アップロードします。少々お待ちください。

----------
　まぁやはりというか、使ってみて思うのは、「重い」の一言でして…。検索自
体は速くても、インデックス作成の重さは、以前テストのために使っていたサー
チクロスよりも断然悪い（=重い）気がします。
[ △ ]
RE:09215 DisplayName[改行][TAB]<mail@adNo.09216
ポン太 さん　05/04/14 12:57
　
秀まるお さん、こんにちは。ポン太 です。


>　で、その処理は封印して、今は鶴亀メールから能動的に呼ばれてAddProperty/
>Sendしています。でもやはり、受信した後にはマシンがとんでもなく重くなりま
>す。鶴亀からのAddProperty/Sendは一瞬で終わるんですが、後々になってGDSが
>実際の処理を始めると重くなって、GDSのインデックスステータスを見ていても、
>メール１通処理するのにかなり時間をかけてやってる様子が分かります。

私は実際の受信でテストがやれないので若干条件は違いますが、まるお さんの
ところのように重くなる現象は確認していません。
何が違うんでしょうね。
もしかしたらGDSをインストール後、既存ファイルのインデックスが作成される
（PCを使用しながらなら１，２日かかります）前にテストを始められて、まだそ
れが終わっていないんじゃないでしょうか？
重いのはメール以外のインデックスの作成とか。


>　あと、僕が思うに、以前AddProperty/Sendしたことがあるメールとまったく同
>じメールをもう一度AddProperty/Sendしても、それはそれで無視されるような気
>がします。だとしたら、「.tkeml」形式にしつつHandleFileメソッドで処理して
>も、大して遅くならない気がします。一番遅いのはGDS側のインデックス作成処
>理でして、鶴亀側がメール用ファイルをAddProperty/Sendする重さよりもそっち
>の方がはるかに重いですので。

私のところではそうは思えないんですが。
とにかくβがアップされたら確認します。


>　まぁやはりというか、使ってみて思うのは、「重い」の一言でして…。検索自
>体は速くても、インデックス作成の重さは、以前テストのために使っていたサー
>チクロスよりも断然悪い（=重い）気がします。

サーチクロスは今でも使っていますが、私のところではサーチクロスのインデッ
クスの作成は激重です。GDSのインデックス作成はほとんど動いていることに気
づいたことはありません。


2005/04/14(木) 12:38　ポン太
[ △ ]
RE:09216 DisplayName[改行][TAB]<mail@adNo.09217
秀まるお さん　05/04/14 13:22
　
　今現在激重状態でメール書いてるんですけど、激重になる原因はメモリ不足の
ようです。僕のパソコンは192Mバイトのメモリしか無いんですが、タスクマネー
ジャで見たら、325Mバイトものメモリを消費しています。

　プラグイン開発用にVisualC++.NET 2003を使ってるのも関係してるんでしょう
けど。

　とにかく早めにβ版公開します。
[ △ ]
RE:09217 DisplayName[改行][TAB]<mail@adNo.09219
ポン太 さん　05/04/14 13:56
　
秀まるお さん、こんにちは。ポン太 です。


>　今現在激重状態でメール書いてるんですけど、激重になる原因はメモリ不足の
>ようです。僕のパソコンは192Mバイトのメモリしか無いんですが、タスクマネー
>ジャで見たら、325Mバイトものメモリを消費しています。

これは全体で325Mバイトということですよね。
私のところのGoogleDesktop*という４つのプロセスの合計は、30Mバイト程度な
ので。


>　とにかく早めにβ版公開します。

よろしくお願いします。


2005/04/14(木) 13:53　ポン太
[ △ ]
RE:09219 DisplayName[改行][TAB]<mail@adNo.09220
秀まるお さん　05/04/14 15:26
　
> これは全体で325Mバイトということですよね。
> 私のところのGoogleDesktop*という４つのプロセスの合計は、30Mバイト程度な
> ので。

　たしかにGoogleDesktop*のプロセスだけ見るとメモリ消費量は少ないんですけ
ど、なぜかパフォーマンスページ中のメモリ使用量を見るととんでもく食ってま
す。共有メモリをそれだけ食ってるってことですかね。

　まぁそれはおいといて、とりあえずβ版が用意できました。使ってみて欲しい
です。

  http://www.hidemaru.interlink.or.jp/software/bin/tk415b1.exe

　この前のバージョンは外国語メールが全滅でしたが、今回はちゃんと外国語
メールもUnicodeメールもちゃんと登録されると思います。しかし、いまいちう
まくヒットしないメールが多いようでして…。迷惑メール類がうまくヒットしな
いケースが多いんですけど。

　ちゃんとインデックスステータス中の電子メールアイテム数か１つ増えても、
その増えたはずのメール中に含まれるワードがヒットしなかったりします？？？
[ △ ]
RE:09220 DisplayName[改行][TAB]<mail@adNo.09221
秀まるお さん　05/04/14 16:32
　
　言い忘れましたけど、「全般的な設定・上級者向け・google連携」という所を
いじらないとダメです。
[ △ ]
RE:09221 DisplayName[改行][TAB]<mail@adNo.09222
ポン太 さん　05/04/14 17:48
　
秀まるお さん、こんにちは。ポン太 です。

>　言い忘れましたけど、「全般的な設定・上級者向け・google連携」という所を
>いじらないとダメです。

16時前からはじめて、32万通が1.5時間程度で完了しました。さすが まるお さ
ん、速いですねぇ。
またGDSには現れてこないようなので、ぼちぼち確認していきます。明日から日
曜まで研修で缶詰なので、確認結果はまた来週にでも。

ありがとうございました。


2005/04/14(木) 17:35　ポン太

というメールをインデックス作成完了後、（たぶん）後で送信アイコンをクリッ
クしたら、鶴亀が落ちました。インデックス作成と関係があるかどうかは分かり
ませんが。


********** 05/04/14 17:39:04.263 4.15beta1  Exception code=C0000005 addr=004
7A22E
eax=00000000 ebx=00000000 ecx=01010101 edx=FFFFFFFF esi=00000108 edi=00930FD
0 ebp=0011E78C esp=0011D430 eip=0047A22E
eip: F6 80 89 0B 00 00 08 75 32 8D 85 78
Stack Dump
00930FD0 00000108 00000000 00000000 00000000 00000000 00000000 10981550
0011D480 00000200 0000000D 00020630 0011DC8C 77E112AB 0069A690 0000000D
00000200 0000065D 00000041 00000A00 0000013C 0000013C 77FCC1D0 00120808
00000034 00F75438 00000000 00000009 0011D730 00020000 0011D4E0 77DF45BF
00330023 00370032 00300037 00300000 00110000 00000009 00000000 00F10004
00020000 77DEE273 0011D730 00000009 0011D7D0 00EB77BE 00000009 001238B0
00000411 0011D520 77E95B00 001238B0 0011D7A8 00000000 0011D7A8 00000009
7FFD8DE6 00000009 0011D7A8 00020000 0011D558 77DF45BF 00000000 00000100
FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Param#5  Param#6  Para
m#7  Param#8  Param#9  Param#10 MachineCode
0011E7D0 004906E6 07544BF0 0000546E 00000111 77DED31C 0011E7D0 0011E7E0 77DE
D3B5 00000000 00000000 00000020 FF 35 EC 4B 53 00 FF 15
0011E980 00470293 00000001 0011F288 0011F290 C0000000 00000000 00000000 020C
3459 00000511 00000033 00000003 E9 F6 14 00 00 8D 87 91
0011E99C 004732F6 0002063A 0000546E 00000000 00000000 0011F290 0011E9BC 77E0
A420 0002063A 0000546E 00000000 FF 75 14 8B F0 FF 75 10
0011E9BC 77E0A420 0002063A 0000546E 00000000 00000000 0011F290 DCBAABCD 0011
EA48 77DE4605 004732C9 0002063A 81 7C 24 04 CD AB BA DC
0011EA48 77DE4605 004732C9 0002063A 0000546E 00000000 00000000 00000000 0000
0000 77E5EDD4 00000004 00000027 8B C8 A1 44 39 E3 77 F6
0011F2A4 77DE5B77 0011F288 00000001 004E00DC 0011F288 00000000 00000000 0000
0000 00000000 00000000 00000000 C2 04 00 8B 4C 24 04 E8
004DF985 00000006 00137C6C 00122F68 7FFDF000 FFFFFFFF 0011D07C 77E70B35 0000
0001 00000000 77F8335D 77FBE810
F7E8016A E80000E2 0000E1E8 010CC4E8 10106800 6A530000 F26CE86E 50590000 3815
FF53 FF00540A 53D70835 CC358B00


17:36:07.060 R 6498 0002063A 0020 003001EA 02000001
17:36:07.060 R 7528 00020630 0020 003001EA 02000001
17:36:07.060 P 1272 003001EA 0200 00000000 00760214
17:36:07.060 r 1301 003001EA 0200 00000000 00760214
17:36:07.247 P 1272 003001EA 0105 00000009 A00F0001
17:36:07.247 r 1301 003001EA 0105 00000009 A00F0001
17:36:07.294 P 1272 003001EA 0101 00000012 C0380001
17:36:07.294 r 1301 003001EA 0101 00000012 C0380001
17:36:07.294 S 6496 0002063A 0086 00000000 00000000
17:36:07.294 S 6496 0002063A 000D 000001FE 0011D744
17:36:07.294 R 6498 0002063A 000D 000001FE 0011D744
17:36:07.294 R 6498 0002063A 0086 00000000 00000000
17:36:07.310 S 6496 0002063A 0006 00000000 00000000
17:36:07.310 S 7503 00020630 000D 00000100 0011DD94
17:36:07.310 R 7528 00020630 000D 00000100 0011DD94
17:36:07.310 R 6498 0002063A 0006 00000000 00000000
17:36:07.310 S 6496 0002063A 001C 00000000 000009A8
17:36:07.310 R 6498 0002063A 001C 00000000 000009A8
17:39:04.013 P 1272 0002063A 546E 00000000 00000000
17:39:04.013 S 6496 0002063A 546E 00000000 00000000
start=08890020 end=089585A4
1432  0    SetReceivedTaskbarIcon Set!
1439  0    本体がアクティブなのでReceivedにしません。
1482  0    常駐アイコンを戻します。
1493  0    本体アイコンを戻します。
5177  0    ProcessTransmitSub() exit
6764  0    LeaveTrans()
6154  0    FreePatrol
9768  0    StartAutoDownTimer()
9776  0    StartAutoDownTimer() set
6782  2593 SetView pTitle=0895845C cb=1921 off=99409
6782  1875 SetView pTitle=08958500 cb=1137 off=101332
6782  672  SetView pTitle=0895845C cb=1921 off=99409
6782  407  SetView pTitle=08958500 cb=1137 off=101332
8506  4046 ProcessCommand 40042
2000  0    DisableDraw
6782  16   SetView pTitle=08EF23F0 cb=4188 off=182422
6782  31   SetView pTitle=08EF23F0 cb=4188 off=182422
6782  0    SetView pTitle=08E80398 cb=3455 off=30084
6787  0    fDisableSetText return
6782  0    SetView pTitle=08EF2498 cb=4168 off=186612
2000  16   EnableDraw
8506  1594 ProcessCommand 40042
8506  422  ProcessCommand 40042
6782  0    SetView pTitle=08EF2510 cb=3121 off=190782
8506  3671 ProcessCommand 40206
6782  0    SetView pTitle=08EF2498 cb=4168 off=186612
8506  344  ProcessCommand 40206
6782  16   SetView pTitle=08958500 cb=1137 off=101332
6782  15   SetView pTitle=08958500 cb=1137 off=101332
6782  0    SetView pTitle=08958500 cb=1137 off=101332
8506  3485 ProcessCommand 40019
14889 31   HmCreate
2544  0    call WinMainSub
2544  0    FrameWndProc: WM_CREATE
2544  0    ClientWndProc: WM_CREATE
2544  0    return WinMainSub
14893 0    HmCreate return
6028  16   InitOuterHidemaru
3632  0    tkinfo 1
3632  0    tkinfo 1
3632  0    tkinfo 86
15135 62   CreateThreadAndViewFrame: waiting hevent OK
15208 0    CreateThreadAndViewFrame() normal exit
6782  10672 SetView pTitle=0895845C cb=1921 off=99409
7158  179313 エディタコマンド: 40054
13384 0    BeginNewAttachList
15229 0    MuteOther()
15269 0    CreateThreadAndViewFrame: waiting hevent OK
10099 0    C:\Online\TuruKame\Yahoo!BB\未送信\未送信20050414_00.txt
478   140  CommandExecEvent 3
15229 0    MuteOther()
15282 0    CreateThreadAndViewFrame: ProcessExecEvent()
596   0    ProcessExecEvent
3893  0    Appended Yahoo!BB/1/ file=未送信20050414_00.txt offset1=0 offset2
=0 size=886
8978  0    NotifyListCacheBaseMoved
[ △ ]
RE:09220 DisplayName[改行][TAB]<mail@adNo.09223
Gertrud さん　05/04/14 19:18
　
Gertrudです。

技術的なことは分からないので、傍から期待をこめて読ませていただいておりま
した。

>　ちゃんとインデックスステータス中の電子メールアイテム数か１つ増えても、
>その増えたはずのメール中に含まれるワードがヒットしなかったりします？？？

私はかなり前から Googleデスクトップを入れていたせいかもしれませんが、受
信直後のメールに含まれる語句ですぐに検索しても、今のところ、ちゃんと検索
結果に含まれてくれていますよ！！


鶴亀単体でも高速に検索できるのに、Googleのほうからも検索できるって面白い
ものですね。正式版、楽しみです。
[ △ ]
RE:09222 DisplayName[改行][TAB]<mail@adNo.09226
秀まるお さん　05/04/15 11:45
　
　すみません。レベルダウンのバグが出てしまいました。かなり簡単に死んでし
まうようです。

　早めに次のβ版をアップロードします。それまでは元のバージョンに戻した方
がいいです。
[ △ ]
RE:09226 DisplayName[改行][TAB]<mail@adNo.09227
秀まるお さん　05/04/15 12:55
　
　ということでV4.15β2をアップロードしました。

  http://www.hidemaru.interlink.or.jp/software/bin/tk415b2.exe

　このバージョンから、「.tkeml」形式ファイルをHandleCacheする処理を復活
しています。さらに、メール用のファイル拡張子が「.tkeml」であった場合には、
そのメールについて、鶴亀メールによる能動的なIndexingは行わないようにしま
した。

　つまり、フォルダ毎の設定でメール用ファイルの拡張子を「.tkeml」に変更し
ておけば、そのフォルダについてのみ、いわゆるgoogleまかせのIndexingがなさ
れることになります。

　これでもし、.tkemlファイルとしてIndexさせた方か調子がいいってことなら、
メール用ファイルの拡張子を「.tkeml」に統一させるようなボタンを「全般的な
設定・上級者向け・google連携」ページに置くという手もあります。

----------------------------------
　僕はまた別の仕事をしようと思うので、ぼちぼちテストお願いします。
[ △ ]
RE:09223 DisplayName[改行][TAB]<mail@adNo.09229
秀まるお さん　05/04/15 13:04
　
　うまく検索できないメールををテキストファイルに保存して、それでしばらく
放置したりしてもダメだったりします。

　でも、そのヒットしないファイルとは別に、もっと内容を単純化したファイル
を作成すると、それはGDSからヒットして、ついでにさっき保存したファイルも
うまくヒットするようになったりします。

　いろいろいじるとまたおかしくなったりして…。やはりまだGDS自体がβ版だ
し、いまいちなケースもあるのかもしれないです。
[ △ ]
RE:09229 DisplayName[改行][TAB]<mail@adNo.09252
Gertrud さん　05/04/17 10:58
　
Gertrudです。

>　うまく検索できないメールををテキストファイルに保存して、それでしばらく
>放置したりしてもダメだったりします。
（略）

そうなんですか。。。テストも大変そうですね。


ポン太さんが「turukame.2:09198| RE 09197 DisplayName[改行][TAB]
<mail@address>のDisplayName」にて、
>あっ、ですがメールのデータ位置を渡す部分のAPI（あるいは登録したメールか
>ら別アプリを起動する方法、「Thunderbirdで表示」に相当する機能）は、まだ
>（おそらく）公開されていないようですから、
（略）

とおっしゃられているように、GDSの検索結果から「鶴亀メールで表示」が出来
れば、完璧だなと思います。詳しい事は知らないのですが、どこかで公開される
といいですね。
[ △ ]
RE:09227 DisplayName[改行][TAB]<mail@adNo.09271
秀まるお さん　05/04/18 14:16
　
　いろいろ使ってみた所、ファイル拡張子を「.tkeml」にしても何もメリットな
さそうです。.tkeml形式にしておけばメール削除とGDS側のキャッシュ削除が連
動するかと思ったんですけど、そうでもないみたいです。

　一応、".tkeml"のファイルを受動的に（googleデスクトップ検索から呼び出さ
れて）インデックス化する処理は残しつつ、鶴亀メール側として、たとえば
ファイル拡張子を".tkeml"に変更するような機能は用意しないことにします。
[ △ ]
RE:09271 DisplayName[改行][TAB]<mail@adNo.09278
ポン太 さん　05/04/21 20:10
　
秀まるお さん、こんにちは。ポン太 です。
１週間ほど使ってみてとりあえず報告です。

>　いろいろ使ってみた所、ファイル拡張子を「.tkeml」にしても何もメリットな
>さそうです。.tkeml形式にしておけばメール削除とGDS側のキャッシュ削除が連
>動するかと思ったんですけど、そうでもないみたいです。

そうですね。削除は反映されないみたいですね。ただ「.tkeml」にしてもGDSに
大きな負荷がかかっているようにも思えないです。まぁ理屈からいって鶴亀が能
動的にという方が良いに決まってますが、体感上は差は感じないです。全部を「.
tkeml」にするのは勇気がいるので、特定のフォルダだけの感想ですが。

GDSの負荷ですが、私のところでは２台のPCで試しましたが、最初のインデック
ス作成時は別にして、通常の運用で問題になったことはありませんでした。ちな
みに２台とも1GBのメモリを積んでます。

「既存のメールをインデックスさせなおす」では30万件が登録されるのですが、
GDSのステータスでは12,3万件しか登録されていません（かなり時間をおいて確
認しました）。再度インデックスさせなおすと1,2万件ほど増えますが、30万件
にはほど遠いです。まぁこれはGDS側の問題かもしれませんので、GDSのβがとれ
るまでは特に確認して頂かなくても良いと思います。

4.15β3をインストールするときに気づいたのですが、TuruKameGDS.dllが上書き
できなくて一旦止まります。GDSを終了する必要があるわけですが、ファイルの
コピー前のどこかの段階で、GDSを終了させた方が良いとのメッセージが必要な
気がします。


私は現在の状態でほぼ満足しています。ありがとうございました。m(_ _)m
（「ほぼ」というのは現状のGDSのSDKだと無理な部分が残っているだけです）


2005/04/21(木) 19:18　ポン太
[ △ ]
RE:09278 DisplayName[改行][TAB]<mail@adNo.09289
秀まるお さん　05/04/22 14:43
　
> 「既存のメールをインデックスさせなおす」では30万件が登録されるのですが、
> GDSのステータスでは12,3万件しか登録されていません

　まったく同じ内容のメールがあると、重複したメールは登録対象にならないよ
うですけど、それにしても少なすぎるようですね。

　もしかしてGDS側から何かエラーが返ってるのかもしれないですけど、エラー
が起きてるかどうかは分からない仕組みです。その辺直します。

> 4.15β3をインストールするときに気づいたのですが、TuruKameGDS.dllが上書き
> できなくて一旦止まります。GDSを終了する必要があるわけですが、ファイルの
> コピー前のどこかの段階で、GDSを終了させた方が良いとのメッセージが必要な
> 気がします。

　ではそのようにインストーラーを修正してみます。
[ △ ]