■ [Q3] Pluggable Namespace Handlers

今までは、昔書いたように、コントロールコンテナサイトにIServiceProviderを実装してQueryServiceでIInternetProtocolを返すようにしていました。しかし、XP SP2から細かな動作が変わったようで、httpのURLを渡してIWebBrowser2::Navigate2を呼び出すとプロセスが死んでしまいます。動作としては、例えばhttp://snak.tdiary.net/にアクセスしようとすると、

1. http://snak.tdiary.net/を引数にIInternetProtocol::Startが呼ばれるが、httpプロトコルなのでE_FAILを返す
2. XP SP2からデフォルトでのリトライがされなくなったため、エラーページを表示しようとして、res://...を引数にIInternetProtocol::Startが呼ばれる
3. 当然ここでもE_FAILを返す
4. 2に戻る

これを繰り返してスタックオーバーフローで死んでしまいます。

そこでPluggable Namespace Handlersの仕組みを使うように変更しました。手順としてはこんな感じです。

1. IInternetProtocolを実装するcoclassを作る
2. 作ったcoclassを生成するクラスファクトリ（IClassFactoryを実装するクラス）を作る
3. CoInternetGetSessionを使って、IInternetSessionインターフェイスを取得する
4. IInternetSession::RegisterNameSpaceを呼び出して、先ほど作ったクラスファクトリのインスタンスを登録する
5. 後は今までと同じようにIInternetProtocolに要求がくる
6. 終了するときには、IInternetSession::UnregisterNameSpaceを呼び出して登録を解除する

IInternetSession::RegisterNameSpaceに渡すCLSIDはいつ使われるのか*1とか、パターンにはどんなものが指定できるのかとかがドキュメントに書いてなくて良くわかりませんが、プロトコルを丸ごとハンドリングする場合にはパターンにはnullを渡しておけば問題ないようです。

■ 余計なIn-Reply-ToやReferencesを付けさせないためのUI

新たにメールを書くときに適当なメールに返信してしまうために無関係なIn-Reply-ToやReferencesが付いてしまうという問題は昔からありますが、メーラ側でうまく防ぐ（勝手にヘッダを取ってしまう）ことはできるでしょうか。

簡単に思いつくのは、

• Subjectが変わっていたら返信ではないとみなす
• 引用が全くなかったら返信ではないとみなす

あたりですが、これはこれで付いて欲しいときに付かなくて困ることになりそうです。

メッセージ作成時のUI上で返信であることをもっと主張してみるという手もありますが、そもそもメッセージ中に返信であるという情報が残るとは思ってもいない人に効果があるかと言われると疑問です。

そもそも新規作成の時にメールアドレスを入力するのが面倒なために返信ボタンを押してしまうということを考えると、既存のメールアドレスに対して簡単に新規メールを送るためのUIが充実していれば返信を使わなくなるのかもしれません。