去年の秋にリリースした2.7.11でほぼ完成というか、安定したものとなっているのですが、経年と共にいろいろと問題点や修正しにくい不具合、それに実装しにくい機能追加要望が出てきていまして、それらをまとめて解決すべく、現在Tonkachiという名前空間でVersion 3.0.0を開発しています、やはりPerlで書いています。
コミュニケーション手段としてのメール(SMTP)はほぼ死んでいるような気もしますが、通知手段としてのメール・IDとしてのメールアドレスはまだまだ死んではいないので、続編の開発をする事にしました。
bounceHammer 2系の問題点
開発者として把握している2系(2.7.11)の問題点としては以下のようなものを認識しています。
- 1通のバウンスメールに2件以上のバウンスがある場合、最初の1件しか取得出来ない
- 一つのシステムとして完結しているのでモジュールとして使いにくい
- O/R MapperでDBIx::Skinnyを使っているけどメンテされてない(Tengに移行すべきか?)
- WebUIでCGI::Applicationを使ってるけどメンテされていない(Mojoliciousに移行?)
- Perl 5.16以降では動かない(use base '...'使ってる)
- 要らん機能が多い(統計出すやつとか人気のないWebUIとか)
- データが大量にある場合、Text::ASCIITable使ってる部分が重い
- メールアドレスを取り出す際のヘッダの走査順序がハードコードされてる
- 依存モジュールが多いのでインストールに時間がかかるしたまに失敗する
bounceHammer Version 2の開発前夜
Version 1はもっと低機能で、Version 2で機能が追加されすぎて、Version 3ではもっと絞ったものになる予定なので、まさに「UNIXという考え方」に書かれている第一システム、第二のシステム、第三のシステムという流れをそのまま進んでいます。
bounceHammer version 3.0.0
前述の問題点を解決すべく、必要な機能だけに絞った堅牢なものとしてbounceHammer version 3.0.0をTonkachiという名前空間で開発しています。早ければ桜の咲く頃か散る頃、遅ければ祇園祭が始まる頃にはリリース出来ると思います、たぶん。
Version 3.0.0の概要
一応モジュールとしては動くのですが、現段階ではSendmailが作ったバウンスメールしか解析出来ないので完成度は20%〜30%ぐらいです。逆に明日の朝起きたら、世の中のMTAが全てSendmailになっていてqmail他全部消滅していたらほぼ完成な状態です。
- 解析用Perlモジュールとしての側面が強くなる
- ↑メールボックスのPATHか中身を渡して解析済のJSONとかYAMLを返すのに特化
- 依存モジュールはなるべく少ないライブラリとして出す
- コマンドラインツールやWebUIは実装するかどうか不明
- HTTPベースでメールのデータをPOSTしたら解析済JSONを返すAPIは作るかも
- 商用MTA対応モジュールも組み込む予定(ExchangeとかNotesとかDominoとかいろいろ)
- Feedback Loopにも対応する(バウンスメールとして扱う)
- PODがそこそこ書かれている(まだ内容は少ない)
- CPANにも置く?
- configureは多分やめる、cpanmでのインストールを前提とする
- 引き続き同じライセンスのオープンソースで公開
Version 2では、ユーザと最も近い部分はbin/以下にインストールされるコマンドラインツールでした。これはメールサーバで解析結果を得えるにはコマンドを実行すれば良いだけの手軽なものでした。一方、開発者の立場で見れば、例えば簡単な1枚スクリプトで解析結果を得て、それを加工するといった用途には使いにくいものでした。
僕自身、とある案件でPerで書かれたメール処理系プログラムに解析処理を組み込む際、わざわざbouncehammer全体をインストールしてというのが面倒に思えた事が何度かあります。
Feedback Loopは日本では導入されているのかどうかわかりませんが、外国、特に欧州のユーザから「FBLもバウンスメールとして扱うべきでしょ」という連絡と追加要望をよく貰います、主にドイツとフランスとスペインから。なのでこれも正式対応する事にしました。
Feedback Loopは日本では導入されているのかどうかわかりませんが、外国、特に欧州のユーザから「FBLもバウンスメールとして扱うべきでしょ」という連絡と追加要望をよく貰います、主にドイツとフランスとスペインから。なのでこれも正式対応する事にしました。
気になっていたツイート
bounceHammerのKanadzuchiモジュールをcpan(cpanm)でインストールできると嬉しいなぁ。パーサーとバウンス解析モジュール群をカジュアルに使いたいのぅ。
— Hayato ｷｭｱ Imai (@hayajo) January 31, 2012
このツイート、二年ほど前ですがずっと気になってました。Version 2はDBからコマンドラインツールから何から何まで揃ってて「こういう風に使ってね」という押しつけがましい感じの物でしたが、解析結果をDBに入れるかファイルに書き出すか、あるいは解析結果の一部だけ取り出すかとか、そのあたりはユーザが自分で好きなものを作る方が良いのではという考えもあり、やっとカジュアルに解析出来るものが作れそうな気がします。
名前空間どうしよう
Version 2系の名前空間がKanadzuchi(なぜzを入れたのかは覚えていない)でしたので、金槌つながりで安易にTonkachi(とんかち)として作り出しています。他にはKinetsukiとかKuginukiとかハンマー系の候補がありましたがTonkachiが一番短いのでTonkachiにしました。名前、リリースまでにもっと良い名前、カッコいい名前が思いついたらそれに変更しますが、今のところ特に思い浮かびません。
あるいはMail::*やEmail::*(これはPEPのMLとかで根回しいるのかな?)でも良さそうな気もしますが、「メールを読みだして解析する+何か」という一連の動作と結果を提供するので、独立した名前空間の方がいいのか悪いのかわかりませんが、たちまち仮名としてTonkachiにしています。BounceHammerという名前空間を使わない理由は、Version 1の名前空間がそうやったので除外しています、長いですし。
Perl以外の言語
次のバージョンはPerlモジュールとして、おそらくはcpanm Tonkachiと実行すればすぐにインストールされてあとはそれを使うスクリプトをユーザが好きに作れば良いという感じになると思いますが、そうなるとPerl以外の言語から解析結果を得る手段がなくなります。
とは言っても、今の2.7.11でそれが出来るかといえばそうではなくて、WebUIのAPIを使ってDBに蓄積されたデータをHTTP+JSONで参照するか、解析結果のYAMLやCSVファイルを読むか、という程度ですが。
なので、Haineko(HTTP+JSONでメール送信する何か)がそうしているように、Plackで小さなhttpdが起動して、それに対してメールボックスのPATHか中身をPOSTすれば解析結果がJSONで返ってくるようなAPIを提供する何かを作る予定ではいます、たぶん。ただ、HTTPを使うかどうかも含めて特に決まってませんし、そのあたりのコードは1行も書いていません。
まとめ
まだまだ作り掛けですが、cpanmでインストール出来るモジュールとしてリリースし、開発者よりの使い方が出来るものになる予定です。
Online baccarat in Canada | Play with £10 Free No Deposit Bonus
返信削除In-depth guide happyluke to baccarat online in Canada. Learn how to play online games, plus learn how to play roulette 바카라사이트 and other ミスティーノ popular casino games.
このサイトは reCAPTCHA で保護され、Google プライバシー ポリシーと利用規約が適用されます。
返信削除mSpy 割引 コード で限定特典をアンロックしてください! この強力な監視ソリューションを割引価格で利用しながら、デジタル世界を保護します。 ペアレンタルコントロールや従業員の監視など、割引料金でオンラインの安全性を強化する機会を活用してください。 mSpy で安心感を確保することをお見逃しなく。
返信削除