2010/7/27
airxmailもいろいろと使ってもらえるようになり、いろいろな人から意見やら、バグ報告やらいただいた。
アメリカやイギリスからも報告をいただき、本当にありがたいことです。
そして、問題もある程度見えてきました。
ただ、説明が不足している部分もあるようなので、時間があるときにデバッグの方法なんかも今後記述したいとは思います。
さて、現在の課題だが、以下の２点だろう。
１） SSL/TLSへの対応。
２） 大きな添付ファイルなどをつけた時に遅いこと。
問題１は、as3cryptoやAIR2のSecureSocketに責任を丸投げしてしまっているところがあったので、
あまり、作るときに真剣に考えなかったが、やはり何らかの対応は必要のようだ。
特に、SMTP over SSL では今のままの形になるが、STARTTLS( いわゆる Port : 587を使う）には何らかの対応が必要だろう。
（といっても、SSL/TLSライブラリを作ることからは始めないので、やはり今のas3cryptoなりの外部ライブラリで対応できなければ厳しい。）
現在、どうしてもgmailのSMTP over SSLで、as3cryptoを使うと通信の途中でエラーが起きてしまうのだ。
しかも、添付ファイルをつけた時に発生する。
また、AIR2でSecureSocketを使うと、今度はなぜかたまに接続に失敗する。接続に成功すれば、こちらは今のところ、1Mクラスの添付ファイルでもおくれるようです。
ただ、どうして接続が失敗するのかはわからないのです。接続自体が失敗しているので、この先に何もできないという状態です。
ということで、今の段階では、できるだけ接続手段を用意するという意味でも、STARTTLSに対応することが必要だろう。
問題２は、Base64のところが遅いのだと思われる。
このあたりも真剣に調査したわけではないのだが、前回、添付ファイルをつけた時にCRLFではなく、
LFにしてしまっていたあたりを調査した際にもはっきりと遅いな－とは思ったものだ。
ただ、こちらもflex標準のクラスを使っていることから、まあとりあえずは仕方がないなとしてしまった。
しかし、やはりエンコード/デコードは外部に出そうと思う。
まあ、そうすればエンコード・デコード部分だけで調査ができるし、ここを最適化するのもしやすくなるだろう。
しかし、これらの問題が解決しない場合も考えられる。
そこで、JAVA-AIRのブリッジという解決策も用意したいと考えている。
まあ、要するに、airxmailを使って送信しているようでも、実はJavaMailのAPIをたたいているだけという事だ。
そのためにも、airxmailのMimeMessageの構造を見直すことと、エンコード・デコードあたりは外部にださないいけないなという感じです。
Posted in 
