[Mew-dist 14162] Re: local spool

[Shigeya Suzuki]

>>>>> "itojun" == Jun-ichiro itojun Hagino <itojun at example.com> writes:

itojun> 	- mewの中にmail取得手順/mail送信手順について共通の
itojun> 	elispの関数呼出方式を決めて

itojun> 	- pop担当/imap担当/mbox担当/Maildir担当に分業できるよ
itojun> 	うにすると言っているのでは。

はい、僕の意味するところは、そこでした。



kazu> できると思う人が設計下さい。pick の API でさえ悩んでいるに僕は、
kazu> 設計できるような気がしません。

この気持は分かるんだけど、切口だけ明快になってれば、それはそれで良い気
がします。


kazu> ホームに落としたときの形式は、とりあえず MH 方式で行きます。ローカルス
kazu> プールと Mew とのやり取りの抽象化が POP だという選択は、そんなに間違っ
kazu> ているとは思えません。

これは、別の視点(に僕には見えるけれど)からは、間違ってないと思います。

たとえば、POP が API というのもたしかに手で、POP から local MH folder 
に取り込む部分の API (elisp base) だけ明快な形で用意し pluggable にし、
Maildir 実装する人がいれば、その人にその形で実装してもらえば良いのでは
ないかと。つまり、できることは、たかが POP 程度と決めてしまう。最小公
倍数を狙うのではなく、最大公約数を狙うっていうかなんというか。

もちろん、これだと、mbox フォーマットを生でアクセスできるようにはでき
ないけど、幸せになれる人が増えるかも。

あと、

kazu> リモートホルダ構想(IMAP の練習)というのがあって、たとえば POP のサーバ
kazu> 側に残しているメールを管理(削除、取得)できるようにする予定です。

結局、やりたいことをやろうとすると、どうしても実装依存になってくるわ
なぁ。。

仮に、↑のAPIができたとすると、Maildir の場合は、この部分はスンナリ実
装できるように思えますが、今度は spool 直接読みはちょっとむずかしい。

kazu> でも、ローカルのスプール(mbox)に対してそんなことは考えたくないなぁ。
kazu> (結局ロックして、mbox の一部を削除できるような C のプログラムを書かな
kazu> いといけない。) やっぱり、POP deamon をローカルで起動してという結論に
kazu> 落ち着くような気がします。

IMAP の練習という意味では良いけど、
POP デーモンを Mew のために上げるぐらいなら、
IMAP にしたいって思う人は多いかも…


shigeya

PS.

ワヤって言葉が、あっち方面の言葉とはしらなかった(笑)