SVX日記

　 今日は代休をとってゆっくりしてしまう。もちろん、おいらにとって「ゆっくり」とは「ゆっくりと作業する」と同義である。ここんとこ経理やら出張やらで忙しく、工作の時間がとれないったらなかった。振り返れば、11月20日の容量計、21日の携帯電話の接着……それ以来ではないか。あー、ストレスが溜まるったらなかったよ。

　 とりあえず、ずーっと懸案だった容量計への脱着式プローブの取り付けを行う。昼間なので心置きなくドリルでガリガリできるのがうれしい。おー、ひさびさのルーターである。ガリガリガリガリガリガリガリガリガリガリガリっとな……たのしーッ!! 穴が開いたら、シャーシリーマで穴を広げる。バナナジャックがキッカリと入る穴を横にふたつ。よっしゃ、完璧。

　 前から気になっていたパネルのキズだが、なんとかゴマかそうとサンドペーパをかけてみる……ガビーン。砂場でコスッたみたいになっちまった。やべぇ。手持ちの一番細かいヤツをかけたんだけどなぁ。えーい、ままよッ!! キッチンペーパーにシンナーかけてコスリまくったれッ!! よし、ちょっと光沢がでてきた。シボ皮っぽいといえば、そんな感じだろう。とりあえず、パネルのキズは消えたし(全面キズだらけともいえるが……)。クルマ用の液体コンパウンドがあったら、再びテッカテカにできたのだろうか？ そのうちやってみようかしらん。

　 で、先日購入したバナナジャックを取り付けつつ、コードの両端にバナナプラグとワニ口をハンダ付けする。よっしゃ、完成。以前に秋葉で格安で買ったミッキーマウスのテープライターを使い、操作パネルに注釈を入れてみる。ちょっと安っぽいが、まぁいい。よしとする。するったらする。

　 さて、ついでにテレビのバイパス手術用のケース加工もしてしまおう。スピーカーコネクタの取り付け場所は大穴を空けなきゃイカンのでちょっと大変だが、最近は経験値が上がってきているのでまぁ楽勝だ。例によって、基板の取り付けネジには皿ネジを使うことにし、皿ネジの埋まるテーパー加工もサクサクと行う。これだけ経験値をたまればレベルアップももうすぐだな。気分的には地下6階のクラーケンを倒せそうな手ごたえ。うほほ。ちなみに小さな部品は左から、ステレオジャック、座金付きLED(緑)、ACアダプタジャックである。

　 で、仮組みしてみる。ちょっとステレオジャックの部分で誤算があったが、概ねキレイに加工できた。さて、明日は実際の回路を組み立てていく予定である。

　 あ、そうそう。ケース上面にスリットがあるが、これは……明日のお楽しみにしておこう。

　 先ほど、テキストベースのメーラ「Mave」のバージョン2.92をリリースした。なんだか、ホントに週刊っぽくなってきたな。

　 しかし、今回もリリース作業には手こずった。イザ世に出すと思うと、結構いろいろと大変なものなのよ。

　 今回は、主にメールフォルダの関係機能を追加した。フォルダの新規作成、フォルダ設定の変更(メールの振り分け)なんかができるようになった。ついでに、試験的ながら、UTF-8以外に、EUC-JPの端末や、SHIFT_JISのWindows環境への対応も開始してみた。おぉッ!! マルチリンガル、エーンド、マルチプラットフォームッ!!

　 相変わらず、メールの送信はできないのだが、次のリリースではインクリメンタルサーチやメールの移動と削除あたりを作り込み、先にメールビューアとして、実用域に踏み込んでいく予定である。では。

　 ウェブサービスなどを構築する場合、メールをトリガに処理をさせるのは良いアイデアだと思っており、事実、多用している。

　 なにが良いって……

・メールを送信できる端末はどこにでもあり、どこからでも要求を送信できる
・メールというインフラは、概ね信頼性が高く、障害でメールが消失しにくい
・任意のタイミングで(周期的に)要求を受信(POP)し、処理できる
・必要なら即座に応答を送信(SMTP)できる
・処理に失敗したら、メールを削除しなければ、再度要求を受信(POP)できる

　 ……などといっても、普通の人にはまったく実感できないことであろうが。要するに、汎用のキュー機構として使い勝手がいいってことだ。

　 ひとつのメールアカウントに到着した要求を、複数のサービスで処理することもできる。fetchmailとprocmailを使い、複数のメールアカウントに転送するのである。各々のサービスは、各々のメールアカウントに到着したメールをトリガとし、メールの内容を見て、自分が処理すべきメールであれば処理し、そうでなければ単に読み捨てればいい。

　 んが、ここで問題。ひとつのメールアカウントに到着した要求を「ホストをまたがった」複数のサービスで処理することが難しいのだ。

　 そんなの、メールアカウントAから、ホストBがメールを受信し、ホストB上のサービスC, D、および、ホストE上のサービスF, Gにメールを転送すればいいじゃん、procmailには、ホスト間のメール転送機能もあるでしょ？ といわれればそのとおりなのだが、それはイマイチなのである。

　 なぜならば、ホストBが死んでしまった場合、ホストEのサービスも止まってしまうからである。そもそも、ホストBとホストEとは対等な立場なのだから、実装も対等にするべきなのである。

　 そうなると、ホストBとホストEが、等しくメールアカウントAにアクセスする構成を採らざるを得ないのだが、ホストBがメールを受信して削除してしまうと、ホストEがメールを受信できなくなってしまう。その逆も起こりうる。片手落ちこの上ない。ならばと、メール受信後もメールを削除しなければ、双方でメールを受信させることが可能になるのだが、今度はメールボックスを溢れさせることになる。

　 んが、この解決は別に難しいことではない。

　 メール受信後も即座にはメールを消さないが、しばらく経ったメールは消す

　 ……という動作ができればいいのだ。しかし、fetchmailにはそのような機能がないようなのである。

　 これ、ニッチな機能のようであって、実はかなり有用な機能なのだ。というのも、複数の環境でメールを処理する場合、例えば、本宅と別宅で同じメール環境を持ちたい場合に「しばらく」の長さを、双方のPOP間隔より長めにすることにより、双方に同じ内容のメールボックスを維持できるようになるからである。

　 というか、それって拙作のメールクライアント「mave」で既に実現されている機能じゃねぇか……というワケで、POP機能の部分だけ切り出し、パイプでprocmailに渡すコードだけ追加してみた。その名も「pinchmail」。「fetchmail」の代わりとなる物件だから、敢えて名前も似せてみた。

　 この「pinchmail」を、ホストB, E の両方に導入し、crontabで周期動作するように設定すれば、両者は対等であり、すべてのメールを処理することができるようになる。

　 パッケージを置いておく。