[Mew-dist 07911] RE: Mew user meeting

1999年 3月 7日 (日) 12:11:55 JST

ユーザ会のメモです。

--
KOIE Hidetaka 鯉江英隆 <hide at example.com>
-------------- next part --------------
<第1回 Mew ユーザ会>
1999年3月6日 13:00 ～ 17:00
日本大学理工学部メディア科学研究室
日本大学理工学部駿河台校舎 8号館 2F

ミューツーの逆襲計画
--------------------        

スライド(magic point)は近いうちにWWWに置く。

                          +-- DataBase
                          |
 Mew --(IMAP)-- daemon ---+-- MH folder
                          |
                          +-- mbox

Mewとdaemonの間はIMAPとか
NNTPのXOVERを拡張したようなのを使うことを考えている。
Perlは起動が遅いのでdaemonにして、これをC/C++で実装する。

DBとしてnamazu,各種freeのSQLエンジンを利用することを考えている。
namazuは全文検索だけしかできない。
DBとしてsony製のGLIMPSEというのもある。

フォルダをアーカイブした状態で扱えるとFAT16のユーザはうれしい。

infoが古くなっている。

Summaryモード
-------------

現在はimlsがctext(compound text)で出力しているが、
imlsにmewが必要とする情報をそのまま渡してくれるようにする。

メイルbodyの部分はMIMEエンコードされていても
imlsはデコードしてくれないのでヤダ。

ctextだとダメな理由
ロシアで使われているkoi-8、特に台湾で使われているbig5がctextに乗らない。

guessとtemplateの統合
---------------------

みんなかんがえてることはいっしょ。
mewで基本的なメカニズムだけ用意しAPIを規定すれば
あとはユーザが勝手に使うだけ。

ぶっこわれたメイルの添付
------------------------

最後がboundaryで終ってないメイルを添付したメイルはこわれてしまう。
どうしたものか。

じつはburstで保存したメイルとyでセーブしたメイルは違うよ、
という話があった(が、私わかってません。)

Draftモード
-----------

caseをつかってimgetを呼ぶことに不安感はないが、
caseをつかってIMにヘッダを作らせるのは、
実際にメイルがどう出てゆくかわからないので恐い。
できるだけmewの方でヘッダを完成させておくのがよいだろう。
IMは配送専門とする。

コンプリーション
----------------

3つのトリガ C-n, TAB, コンマ が考えられる。
C-n: circulateする方法が好みでないという意見があった。

Crypto
------

リメーラーサイトがあって、これをまとめるサービスも存在する。
ユーザが指定したSMTPサーバに次々と中継させることによって
送信者の特定を困難にする。政治的発言が難しい地域で重宝するらしい。
mewからもこれが利用できるようになるとうれしい。

    Sender ------> Remailer site 1
                        |
                        V
                   Remailer site 2
                        |
                        :
                        V
                   Remailer site N ------> Receiver

POP extension
-------------

IMの方でput拡張に対応してくれると嬉しい。

Open Relayを警戒するSMTPサーバが多いので、
認証が使えるAPOPでメイルを送信できるのはメリットがある。

     User <---(POP)--- Server <---(SMTP)---> Internet
      |                 A
      |                 |
      +------(SMTP)-----+

     User <---(POP)---> Server <---(SMTP)---> Internet

SSH (Secure SHell)
------------------

imgetでSSHポートフォワーディングを利用できるように
IMを改造するのは、Imget.Srcの書き方を拡張しないといけないし、
IMの下層部分へその情報を上手く伝達するところが困難であったため断念した。
単にshellスクリプトで実現するのは難しくない。

fetchmailをつかえば簡単にできるらしい。

モバイルする人はssh -Cによる圧縮が効くのでうれしい。

mailto.el/mew-mailto.el
-----------------------

たとえば、メイルヘッダにList-Unsubscribe:があったら
これをつかって脱会メイルを書ける。

くわしくはrfc236[89].txtで規定されている。

このフィールドを付けるMLも増えてきているらしい。

この辺の入会/脱会の情報はサーチエンジンの方で勝手に収集してくれるといいな。

CT:text/html
------------

そろそろXemacsではデフォルトでW3が起動するようにしてもいい。

BBDB
----

BBDBというアドレス帳みたいなもんは重いので使いたくない。
Petnameやaliasとの統合を考えたとき、似たようなものになるのではないか。

thread表示
----------

mew2になってDBが導入されてから考えよう。
ワンダーなんとか というメイラーでのthread表示がなかなかよいらしい。

elispで実装したthread機能
-------------------------

Medow on Windowsで長いことつかっているが、問題はなさそう。
あとはマニュアルを書くだけ。

thread表示に必要な情報はmewで保持する。

メイルのget/putは従来どおりIMで行う。

thread表示のためのDBはelispの形式で保存する。

メイルが約16000個のときDBの大きさは約4MBになる。

通常のmewに比べemacsのメモリ消費量は10MBくらい増える。

alistでDBを作ると文字列の比較が必要なので遅いが
obarrayというemacsの下位データ構造を利用するとシンボルの比較で
実現できるので速い。つまりsearchが速い。

obarrayは全てのemacsで使えるはずなのでportabilityの問題はない。

summaryを表示するのはimlsに比較すると3倍くらい遅いが
頻繁に行うものではないので問題はないと考える。

thread化はredrawまで遅延する。メイルをgetしたときはthread化しない。
これは到着順でメイルを読みたい、あるいは新着メイルのうち必要なもの
だけ選択して読みたいから。

thread表示するためにredrawすると26秒かかった。
2度目のredrawはキャッシュが効いて16秒くらいで済む。

thread化に必要な情報はscan formatを工夫することによって
IMからmewに提供できないだろうか、というのは昔からいわれている。

MSのメイラーはthreadをぶったぎるので、
対策としてsubjectが同じものを検索する機能を実装してある。
同じsubjectかどうかの判定をするときにあらかじめ余計な空白を除いておく。

実装はmewへのパッチではなくad-add-adviceというのをつかって
after/before methodのような感じで呼び出しているらしい。

要望としてフォルダごとにthread表示したいかどうかを指定できるように
してほしい。現在の実装では全てのフォルダがthread表示される。

queryのhistory
--------------

folder setの管理とかルール一覧をみれたらいいな。
とにかく皆、考えてることは一緒らしい。

iCalendar
---------

rfc2445.txt(Internet Calendaring and Scheduling Core Object Specification)
Tkの実装がある。

Petname
-------

なぜNicknameでないかというと、
昔のIMがオプションの1文字目しか扱わなくて
nがすでに使われてしまっていたため、じゃぁPetnameにしよう、
ということになって今に至る。

PetnameとAlias、To:へのコメント付加機能の統合
---------------------------------------------

petnameとAliasを両方使っている人なんていない?

統合したら、それはアドレス帳になるのか。

.im/Petnamesと.im/Aliasesをなんとか1つのファイルにするための
フォーマットがいくつか提案された。

To:のところが勝手に
     Kazu Yamamoto (山本和彦) <kazu at example.com>
とされるのは気に入らないが、superciteが
  kazu> これは、supercite で勝手に名前を付けられるのと同じ問題であり、止めよう
  kazu> にも止められないということで意見が一致しました。というわけで、
  kazu> 	- 実装するけど
  kazu> 	- デフォルトにはしない
  kazu> で僕は妥協します。
  kazu> これで合意は得られますか？
というふうにやるのは納得できるのはなぜか?
引用した行すべてに xxx> なんてやるのは人間技ではないから許せるのでは。

To: "Kazu Yamamoto (山本和彦)" <kazu at example.com>
になる場合、ダブルクォーテーションを外してあげるのはおもしろくない。

鯉江英隆 <hide at example.com>