某サイトの掲示板の内容を RSS で配信しようと思って、xxx.rdf ファイルを作成したのだが、IE6で読み込もうとすると、なんと PowerDVD が立ち上がる。
おかしいなぁ、さっきはちゃんと xml ファイルとして認識してくれたのに。

たぶん、あの悪名高き、IEの content-type 無視 --- 自動判定処理が悪さしているのだろう。
とりあえず、ファイルタイプとPowerDVDの関連は削除しておいたけれど、また、何かの拍子に復活するのだろう。
( CyberLinkもかなり行儀が悪い。スタートメニューの階層の深いところに押し込んでやっても、いつのまにか一番上に勝手にショートカットを作成してくる。プレインストールのソフトだから放置しているけれど、絶対にソフトウェアを購入したくない会社だな。)

QuickTime と Safari (その2)

いろいろ調べてわかったことは、
1. QuickTimeも、7.x 系列では それ以前と javascriptによるコントロール方法が、かなり違うということ。
2. Windows2000 では、7.1.6 が動作可能な最終版ということ。
3. 7.0, 7.1系列の QuickTimeにはかなり深刻なセキュリティ上の問題があるらしいこと。Firefox では、7.0、7.1系列は非サポート(通常の方法ではプラグインをインストールできない -- 裏技が必要)だということ。
4. Safari や Opera では、Play や Stop といった関数が使えないらしく、音を出すときは、object を生成、音を消すときは object そのものを削除 といった荒っぽいことをしないといけないらしい。( 当然、Pause も使えない )

ということらしい。
そういうわけなので、6.5を切り捨ててよいという情況ではまだないし、最近の版の QuickTimeで用意されている細かい制御方法も、Safari や Opera上ではあまり期待できない。
Pauseが使えるか使えないか、といった判断を組み込まないと、それぞれの環境の中でもっとも相応しい処理ができないので、もし、それを避けたいのなら Start/Stop以上の制御はできない( ということは、現在 IEやFirefoxでできていることができなくなる)ということ。

まあ、時間が無限にあれば、きめ細かく場合分けするのだろうけれど、どこかで適当に見切りをつけないと...

QuickTime と Safari

事情があって QuickTimeのバージョンを 6.5 から上げられなかったのだけれど、もしかしたら、QT7 だと、Safariからも QTをコントロールできるのかもしれない。

Ajax と MediaPlayer

やっぱり、互換性の泥沼に嵌ってしまいそう...
<embed src="..." > だと、MediaPlayer の場合 srcを書き直しても、新しいソースを読み込んでくれない。 Firefox + QuickTimeなら読み直してくれるのに。

<object ... なら、よんでくれるのだろうか？ そうすると、Playerの種類ごとに違うスクリプトを書かないといけないのだろうか... 考えただけでも、気が重くなるので、この辺で抛り出すかも。

lighttpd

lighttpd が速いらしい、ということでちょっと試してみたのだけれど、素のままのインストールだと、MPMモードのapache方が、圧倒的に速い。( apacheの方は、長年にわたってチューニングしてあるので、公平な比較ではない。)
掲示板のcgiが apache2だと 200〜300msなのに対して、lighttdだと mod_cgi で 2秒近くかかる。
たぶん、fast-cgi の設定とかこまごまとしないと本来の速さがでないのだろう。

tomcatの関係で ajp13が使える 1.5(prerelease/trunk)しか評価していないのだけれど、1.4.x系列の説明がどこまで有効なのか解り難い。まあ、これはしかたないか。

某無料サーバー (その２)

落ちていることが多いと思ったら、システムの入れ替えをしていたのかも...
昨日まで動いていた javascript が今日になったら動かなくなっているので、調べてみたら、XMLファイルの MIMEタイプが、application/octet-stream になっていた。
application/xml で返して欲しいのだけれど...

---
.xml ファイルの MIMEタイプを直すようにお願いしたら、即刻直してくれた　:-)
ただ、.xsl ファイルの MIMEタイプを直して貰うのをお願いしわすれた...
まあ、こちらはファイル名を直せば回避できるので、(ちょっと気持ち悪いけれども)よしとする。

某無料サーバー

機能はほとんどないものの、安定性だけは優秀だったので、お気に入りのサーバーだったのだけれど、最近落ちている頻度が少し増えたような気がする。
コントロールパネルにも入れないので、アクセス制限ではなくて、ほんとに止まっているのだろう。

Ajax と Safari

Safari だと、ときどき文字化けする。
「ときどき」というのは、長いテキストの、ほんの１文字だけが化ける、という状態。

経験的には、こういう症状は、バッファの大きさの境界を文字が跨いだ場合の処理がダメダメだとおきることが多いのだけれど、どうなんだろう。( そんなに間抜けなプログラマが開発しているとは思いたくない)

検索してみると、Safariと HTTPRequest 絡みのトラブルはわんさか見つかるので、有名なバグなんだろう。ただ、そこに書いてある対処法では直らないなぁ。キャッシュは無効にしてある(はず)なので、キャッシュのせいではないと思うのだけれど...


... 簡単に対応できるなら対応するけれども、本質的にSafariのバグっぽいので、Safariのバグ修正待ち になるのだろう。

---
Google Chromeでも、全く同じ症状。ということは、共通に使われている Webkit のバグだね。

Ajax と IE (続き)

IE だと、<xml src="..."> なんてタグが使えるのね...
もう使うべきタグじゃないのだろうけれど、バグっぽい奇妙な振る舞いさえなければ(というか、実際、かなり挙動不審)...

やっぱり、正攻法で MSXMLを使うべきか？
MSXMLを呼び出すと ActiveXを有効にしないといけないので、ダイアローグがでて鬱陶しいのが難点なのだが、ActiveXを defaultで無効にしているようなユーザー層は、とっくにIEを捨てて他のブラウザに引っ越していると考えていいのかな。

---

Google の ajaxslt なるものを読んでみたら、なんと、javascriptから xslt を呼び出すのではなくて、「javascriptでxsltを書いている」のね。remarks には、

Internet Explorer exposes XSLT via the transformNode() method on the
XML DOM. However, this is not avaiable if ActiveX is disabled.

なんて書いてある。やっぱり ActiveXを有効にするのにはちょっと抵抗があったらしい。

となると、問題は処理スピード(と、firefoxのようにXSLTが組み込まれている場合に特別な処理がされているか)だな。

---
やっぱり ajaxslt の利用は見送り。ファイルが大きすぎる。
( それに、jquery 用にポートされたものは、なんだかバグっぽい。)
IEのデフォールトのインストール状態では ActiveX は有効のようだし、ActiveX の危険性を認識しているユーザーは IEなんか使わない、ということで transformNode を使うことに決定。

Ajax と IE

...やっぱり、IE対応は鬼門だな。ブラウザの違いを吸収してくれるはずのライブラリを使用しているのに、挙動が微妙に違う。
検索してみると、いろいろヒットするので、たぶんよくある症状で、解決法もじきに見つかるのだろう。
( たぶん、エラーのときの callback をもっと丁寧に書かないといけないのだろう。用途的には、別に非同期処理でなく同期処理でも全く問題ないところなのだが... )