つれずれなるままの開発日記(最近はFlexばかり..)

そこそこバグ修正やら問題対応やら、追加機能を行い、Rev65をGoogle Codeに上げました。
これをもうちょっと、テストしつつ、バージョンを 0.6 にしようとおもいます。

追記：
————————————————————————————————————-
バグがありましたので、Rev66にしました。
やっぱり、ちょっと気がついたレベルで直したのがよくなかったとおもいました・・・・
————————————————————————————————————-

さて、今回の対応ですが、大きく分けて以下の対応があります。

１） 送信処理で画面の方が固まってしまうことがないようにする対応。

こちらは、AIR2 SecureSocket とgmailの組み合わせで非常に起きてしまっていました。
gmailはデータの書き込み(flush()) 処理に時間がかかるようで、そこで画面の方まで固まってしまいました。
そこで、一度ByteArrayに出力してから、サイズを細かく分割して、さらにTimer処理にしました。
（このあたりの、ノウハウが今ひとつわからず、四苦八苦です。)

このサイズを変えるのは

SMTPSender.setParameter(SMTPSender.BUFFER_SIZE,1024*20);

デフォルトは、16234です。
こちらTLSに関連する数字なのですが、実はこの対応をしているうちに、3)の問題が解決しているっぽいことが判明。
根拠が正確にわからないので、真偽はさだかではありませんが、明らかに問題がでていたのが、いまのところ再現しなくなりました。

また、ネットワークが早く、小さいメールしか送らない場合で、この機能を使いたくない場合には、

  SMTPSender.setParameter(SMTPSender.ENABLE_BUFFER,false);

２） 接続がうまくいかなかったときの対応の強化。

こちらも SecureSocketとgmailで初めのネゴシエーションが異常に時間がかかります。
こちらを接続命令を出してから、5秒でタイムアウトとしていたのを、
接続が完了してから、10秒以上サーバから 220のステータスがかえってこない場合にタイムアウト処理にしました。

ちなみに、この時間を変えるのは

 SMTPSender.setParameter(SMTPSender.CONNECTION_TIMEOUT,5000); // default 10000 -> mean 10 sec

３） gmailとas3crypto を使ったときに、添付ファイルが大きいと接続が切られてしまうことの改善。

こちらは、１）で記述したので省略。
ただし、as3crypto 1.3 のバグを発見。Socketをcloseしたあとにflush()をしていたので、エラーが起きていた。
ごくまれに起きる。すでにquitしたあとに、起きているエラーなので、無視しても問題無いと思えば問題無い。
ソースを見るとtrunkでは直ってるぽいです。

４） STARTTLS への対応

// comment out
// use plain socket
//sender.setParameter(SMTPSender.SOCKET_OBJECT,new TLSSocket());

sender.addEventListener(SMTPEvent.SMTP_START_TLS,startTlsHandler);

public function startTlsHandler(event:SMTPEvent):void{
	var sock:Object = event.socket as Socket;
	var tls:TLSSocket = new TLSSocket();
	sender.setParameter(SMTPSender.SOCKET_OBJECT,tls);
	tls.startTLS(sock,"your.smtp.host.name");
}

みたいな感じで。
みそは、初めは通常のSocketを使うのですが、STARTTLSで、socketオブジェクトを設定し直す必要があります。
そして、その後、startTLSメソッドを投げます。”your.host.name” はどこまで意味があるのかは不明です。(as3cryptoをそこまで見切れていません。）
あとは、使い方は変わりません。

５） Thunderbird でサブジェクトが文字化けすることのバグ修正。

Thunderbirdのながーいサブジェクトが文字化けしていました。（MIMEで改行が入る場合）
こちらも修正。
むかーしは、WebMailがたいていおかしくて、すべて１行で書いてしまうのがよかったのですが、
今はどんなかんじが現実問題ないのかがわからないのですが、見ている感じThunderbirdが厳しいみたいなので・・・・・

あと、細かいあれこれを・・・・・ちょこちょことやっています。

さて、いろいろやってみて、思ったことは、
AIR2のSecureSocketよりも、 as3cryptoの方が何かと都合がいいなと感じました。
それは、まず、なぜがかas3crypto のほうが早い。体感なので、厳密にはわかりません。
とくに、gmail の接続がSecureSocketではうまくいかないことと、成功しても遅いことが多々あるのです。
あとは、画面処理に影響が少ない気がします。
どうしてもSecureSocketのflush()処理で、画面がカクカクしてしまうのです。
Timer処理と、一度に書き出す量(buffer size)を調整することが必要な気がします。
(as3cryptoでは今のところ、それはありません。）

STARTTLSみたいに、途中からTLSという接続もできないのですが、as3cryptoなら可能です。

前回、課題をのせましたが、もうちょっと詳細に問題が見えてきました。

１）SSL/TLSへの対応
この問題の一部で、SecureSocketを使ってgmailの465(いわゆる smtp over ssl )につないだときに、なぜか今まで接続に失敗することがあった。

実はこれ、私が明示的に作っていたタイムアウトで切断されていだけでした。
たとえば、SMTP over SSLが必須にも関わらず、通常のプレーンなSocketでつないでしまった場合も考えて、
接続に成功しても、220のステータスがある時間（デフォルトで5秒) 帰ってこなければエラーにしていたのですが、gmailだと接続に時間がかかるときがあるらしく、
この制限に引っかかってしまっていました。
まさかそんなにかからないと思っていたので、疑ってもいませんでした。（とほほ・・・）
あと、その設定を変えられるようにしていませんでした。

なので、この制限のデフォルトを伸ばすこと(10秒）と、設定を変更できるようにします。

２）大きな添付ファイルなどをつけた時に遅いこと。
こちら、以前はBase64が遅いといいましたが、こちらもおそいのですが、
それ以上に、SecureSocketのflush()メソッドが遅いことがわかりました。
実際 800kのファイルを添付するのに、私のPCで1秒弱かかっていますが、それをBase64したあとに、
writeUTFBytes()して、flush()するのですが、
このflush()だけで、8秒弱かかっています。

ただし、原因はわかりません。ネットワークの上りがおそいのでしょうか？
それとも、大きなデータを一括でflush()してはいけないのでしょうか？（といってもそれほど大きくないともおもうが・・・）

ただ、この8秒という時間が、「応答なし」という状態を作ってしまうのはちょっといただけないなと。

このあたりを修正して、近いうちにバージョン 0.6としてアップできればと思います。

実はこの間、ある会社の経営者とHTML5についてお話をしました。
そこで、HTML5についてずいぶん違った認識をもっているのだなーと。

HTML5をFlashと比べる方が多いので、どうやら、アニメーション機能をもっていると思っている方が多いようです。
残念ながらHTML5は、アニメーション機能は持っていません。
HTML5 + JS でアニメーションを作れるという事です。

また、基本的にはFlashでできない表現が、HTML5でできるようになったかと言えば、そうでもありません。
と、このように伝えると、なんだかHTML5に対する大きな期待がなくなってしまったようです。

じゃ、なぜこれほどHTML5が騒がれているのでしょうか？
というよりも、騒ぐ必要があるから騒いでいるという側面があるのではないでしょうか？

まず、Flashですが、Flashは長い間、ずーとクローズドでやってきました。
すると、昨今のオープンの波の為もあり、HTML + JavaScriptである部分、代替する人がちらほらと出始めました。

なーんだ、限定した使い方ならFlashじゃなくても、HTML + JSでいけるじゃん。
それに、チープな動きからだんたんとオープンのまま、進展してきたこともあり、オープンの波は大きくなります。

現在はおおよそはいけるんじゃないの？ってところまではきたと思います。
まあ、これはアニメーション型サイトから、コミュニケーション型サイトへ移ってきたことも、影響が大きいでしょう。
昔みたいに派手でこっていたアニメーションが嫌われることになったし、芸術的なサイトよりも、
機能的なサイトの方が価値が出始めてきました。

ただし、後一歩のところで、いろいろな意味でFlashに追いつかないのです。
それは細かい動きの部分もありますし、IEだとひたすら遅いとか・・・・

ここで、HTML5になればどうなるでしょうか？

まず、ブラウザが新しくなります。
当たり前ですが、これがブラウザを作っている方達からのHTML5を進める利点です。
これで細かい表現の違いによる影響が今よりは改善されるはずです。
ここで、IEの牙城を崩せればと思うはずです。

さらにブラウザを新しくするにはOSが新しくなります。（なりやすい）
大多数の方はブラウザだけをインストールなんてしません。
初めから入っているブラウザを使います。

そしてOSが新しくなれば、ハードが新しくなります。（同様になりやすい）
こちらも、OSだけの再インストールもしません。
最近ではOSのインストールもしたことがない、技術者だった当たり前にいるくらいですから・・・
つまり、速度は速くなります。
これで、速度面も解決していきます。

これだけでしょうか？
実は大きなのはコミュニティではないでしょうか？
なんか、LinuxとSolarisにちょっとにている気がします。

Linuxが不完全でチープで小さいうちにオープンに広まったからこそ、
その内部を知っている人が多く出てきました。
一方、Solarisは今でもLinuxよりもOSとしては完成されているのかもしれませんが、
今更オープンにしても、なかなか中身を見るには大きすぎるのです。
つまり、変化に勢いを感じることができないのです。

要するに、人の世代交換が、物の世代交換になったという事で、
物自体の価値というのはそれほど大きくはないのではないでしょうか？

ということで、HTML5が部分的にはFlashに変わっていくことはやむを得ない気がします。

しかし、一方で不安があります。
それは、プログラムがわからないデザイナがHTML5向けに使えるエディタが世の中に出てくるのか？
Adobeが自らのFlashをいらないと言わせるほどの、Dreamweaverを作るのか・・・とか。

あとは今まで、プログラムのソースを完全に自動で出力するツールが世の中で普及した事実を私は知りません。
それは、機能を作るのがプログラムであったから普及することが過去なかっただけなのか、それとも実用に耐えうるものができないからなのかは、
私には今のところはわかりません。

それと、もう一つ。
今でも、Ajaxのサイトは増えています。今はHTMLアプリはここが危険だ。とさんざん苦労して来た人たちがまだまだ作っています。
しかし、今から作るエンジニアをたくさん増えているのでしょうが、
それと同時に「危険だな－」という作りを平気でしてきます。
つまり、ちょっと詳しくなれば、「あー、これは簡単に攻撃ができるな」というサイトもたくさん出てくることでしょう。
かつて、CGIは難しいという時代に、PHPという言語は簡単なために急速に広まっていきましたが、一方で危険な言語の烙印も押されてしまいました。
そのおかげで、PHPという言語はバージョンが上がる毎にどんどん難しくなっています。
それはPHPという言語が危険というより、それを使う人のスキルが危険ということで、
それでも安全なようにと便利な機能がだんだんとなくなっていったのです。
（よい言い方をすれば、エンタープライズ向けになったという事です。）

そうすると、HTML5 + JSのサイトは危険な可能性があり、もっとセキュリティを考慮した物じゃないとだめだ－と声を上げる人も出てくるでしょう。
そしたら、FlashのPlayerにセキュリティホールがあろうと、Flashのほうがまだましだとなるかもしれません。
(Flash PlayerのセキュリティホールはAdobeさんが直しますが、自社で作ったJSのセキュリティホールは誰も直してくれませんから・・・）

ただし、どちらにしても言えることが、「必要以上に難しくなった」という気がします。
見た目のデザインと動きのデザインと、処理ロジックの３つの能力が必要になってきてしまったのですから・・・

前回、記したgmail port:587 での送信をas3cryptoを使用し試みた。
このために、airxmailもstarttlsコマンドに対応をした。

結果は・・・・・
SMTP over SSLと変わらず。
もしかして、ポートが異なれば違う動きをするかも？と淡い期待をしてみたが、やはり結果は同じだった。
メールサイズが大きくなると、エラーになってしまう。
（小さい物だと問題無いのも同様。）

まあ、結果的に同じ結果になったが、ほかのサーバでうまく動くケースもあるかもしれないので、
ただ、せっかくなので一応、後でgoogle codeのほうにコミットしておくことにはします。

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の構造を見直すことと、エンコード・デコードあたりは外部にださないいけないなという感じです。