[Mew-dist 17323] Re: Could config support a queuing switch?

[Hiroyuki CHIBA]

  千葉＠日立です。

有益なアドバイスをありがとうございます。

>>>>> On Thu, 10 May 2001 07:28:30 +0900,
	Tatsuya Kinoshita <tats at example.com> said
	 about: [Mew-dist 17312] Re: Could config support a queuing switch?:

tats> In message "[Mew-dist 17309] Could config support a queuing switch?"
tats> Hiroyuki CHIBA <hiro at example.com> wrote:
tats> >   (1) 送信可能なSMTPサーバがあれば送ればよい。
tats> >   (2) 別の理由でキューイングしたい場合には、ユーザが明示する。
tats> >       (この理由は良くわからないですが、もしかして、キューを未送信のド
tats> >        ラフトの管理場所として使うことが想定されていますか?)

tats> キューは、完成したメールをプレビューできる場所です。また、常時接続
tats> でない環境だと、オフラインで書いたメールをキューに入れておいて、接
tats> 続してからまとめて送信するのが普通だと思います。

すなわち、
  (1)完成したメールをプレビューする場所、かつ、
  (2)常時接続でない環境において、オフライン時にメールを貯めておく場所
という２つの役割を持っているわけですよね。

私にとっては、(1)は、メール作成、送信時にユーザが意識すべき対象であり、
(2)は、メール作成時には意識したくない対象なのです。;_;
# 私の使い方にクセがあるということかもしれないですが、MUAを思考支援ツー
# ルととらえると凄く重要なことだと思うんです。

tats> なお、キューに入れたメールは、ドラフト作成時のcaseではなく、送信時
tats> 点でのmew-config-outputをcaseとして、そのcaseに対応したSMTPサーバを
tats> 使って送信されるので、たとえば、ノートPCを使っていてドラフト作成時
tats> と送信時とで送信環境が変わった場合でも、mew-config-outputを送信時の
tats> 環境に合わせることで対応できるようになっています。

なるほど、送信時に mew-config-output を書き換えれば良い訳ですね。

ところで、別のスレッドで、作成時の case の保存の是非が議論されています
が、個人的には、どちらも必要と思います。あと、編集中の任意のタイミング
で、ユーザが簡単に指定できると嬉しいです。
本質的に、From: フィールド等のメイルヘッダ情報と、SMTPサーバ等のネット
ワーク情報は、別に扱う方が良いように思っています。

それぞれのタイミングによって、これらの２種の情報は、以下の様に違っています。
 1) 新規にdraftを準備した時
    メイルヘッダ情報： 確定していない(デフォルトを指定できるのみ)
    ネットワーク情報： その時のネットワーク環境が想定される
 2) 返信によりdraftを準備した時
    メイルヘッダ情報： 返信元メールのヘッダ情報が取得可能
    ネットワーク情報： その時のネットワーク環境が想定される
 3) draft作成中(ユーザによるトリガ)
    メイルヘッダ情報： ユーザにより設定された、より確かな情報が取得可能
    ネットワーク情報： その時のネットワーク環境が想定される(ユーザが意図)
 4) draftメッセージを送信する時(キューイングされる可能性あり)
    メイルヘッダ情報： すべてのヘッダ情報が確定されている
    ネットワーク情報： 送信時のネットワーク環境が確定される。
 5) キューイングされたメッセージを編集する時(ユーザによるトリガ)
    メイルヘッダ情報： キューイング時に確定しているが、ユーザの指定に
                       よって、修正される可能性がある。
    ネットワーク情報： その時のネットワーク環境が想定される
 6) キューイングされたメッセージを送信する時
    メイルヘッダ情報： キューイング時に確定しているので、修正の余地はない。
    ネットワーク情報： その時のネットワーク環境が想定される

tats> また、特定の送信環境でのみ送信したいメールのため、キューフォルダを
tats> caseごとに分けて、メールが混在しないようにすることもできます。設定
tats> 例は下記のとおりです。
tats> (setq mew-config-alist
tats>       '(
tats> 	("isp"
tats> 	 ("queue-folder" . "+queue")
tats> 	 ("user" . "isp-user")
tats> 	 ("mail-domain" . "isp.foo.jp")
tats> 	 ("smtp-server" . "smtp.isp.foo.jp")
tats> 	 )
tats> 	("lan"
tats> 	 ("queue-folder" . "+queue-lan")
tats> 	 ("user" . "lan-user")
tats> 	 ("mail-domain" . "lan.foo.jp")
tats> 	 ("smtp-server" . "smtp.lan.foo.jp")
tats> 	 )
tats> 	))

キューをあとから編集したり、複数のFrom:アドレスを使いわける場合には、
便利な機能ですね。
私の状況では、キューイングをなるべく意識したく無いので、現時点では、
queue の色分けを使いこなせないです。
# 機能を否定しているわけではありませんので、誤解なきよう。:-)

あとやっぱり、メイルヘッダ情報とネットワーク情報が直交しているといいなぁ、
と思います。
# 例えば、他の case をインクルードできると嬉しいです。

tats> >   (2) メール作成時(メール作成して、C-cC-cするまで)は、常に同じ操作で行
tats> >       いたい。
tats> > 1. config で、送信時の queuing を指定する仕様の是非(実現可能性も)
tats> > 2. draft 作成時に、config の値を設定する外部関数を登録できるhook
tats> >   (既に現行の仕様でできるなら、私の理解不足です。ご指摘ください。)

tats> mew-draft-mode-hookで、ドラフトモードでのC-c C-cの割り当てを変更す
tats> れば、キューイングを指定できそうです。

ありがとうございます。トライしてみます。

論点がまとまらずに、長くなって申し訳ないです。

# 現在、日本に帰国する飛行機の中で、このメイルを書いています。
# 到着後に、queue をflush します。:-)

----
千葉　寛之 : hiro at example.com clin at example.com
（株）日立製作所 ビジネスソリューション事業部
 phone: 044-549-1713(Dial-in)  fax: 044-549-1721