今日はDexadorについて話します。Lispには古くからDrakmaというHTTPクライアントがあります。よると74のライブラリで利用されており広く使われているようです。Lispをやっている人のほとんどは知っているでしょう。cl-ppcreやHunchentootのようなテクニカルであり高速であり品質の高いライブラリを多く作っています。Weitzのプロダクトです。Drakmaも彼のプロダクトならば信頼できるか、と言うと、実は期待するほどは品質が高くありません。Drakmaを使ってハマったという人も少なくないのではないでしょうか。よしdrakma:http-requestにURLを渡せばいいのかな。あれ、日本語クエリ含む場合にちゃんとGETしてくれない。なんか自動でASCIIでデコード・エンコードされるなあ。tを渡せばいいらしい。...あれ、エンコーディングエラーが出てる。Shift_JISのページは対応してないのかー。tを渡して自分でBabelでデコードするしかないなあ。Content-Typeヘッダを雑にパースして...。...あれ、意図しないHTMLが返ってきてる。うーん、手元ではうまくいくんだけどなあ。503が返ってきてるみたいだ。ステータスコードを見て4xxと5xxのときはエラーにしなきゃなあ。できれば何度かリトライもしたい。やってるとコードがとても複雑になってきます。我々はただHTTPリクエスト投げたいだけなのに。Meetupでの発表資料に詳しくまとめています。fukamachi曖昧にDrakmaで使いづらいと思っている内容を明確にリストアップしています。2015年8月26日twitter.comこういった状況を改善すべく、よりよいAPIを提供することでDrakmaを置き換えられないかなと考えました。そこで作ったのが「Dexador」です。新しくHTTPクライアントを作ることは可能でしょうが、使ってもらわなければ意味がありません。その観点から言うと「Drakmaより良いAPIを提供します」というだけでは不十分だとは感じていました。「良い、なんてものは主観的だ」と言われればそれまでです。細かい改善も伝わりづらく、なかなか移行するほどアピールできるとは思えません。そこで思い至ったのが高速化です。Wooで作ったfast-httpやQURIを使うことでDrakmaよりも圧倒的に高速になれば優位性が数値として証明できます。これは良い戦略かと思われたのですが、fast-httpとQURIでは1.2倍程度の速度しか出ませんでした。そこで最大のボトルネックであるコネクション確立部分をスキップすることでさらなる高速化を行いました。マクロレスエラーハンドリングDexadorの売りの一つは4xxや5xx系のステータスコードが返ってきたときはエラーを発生するということです。そのエラーハンドリングをしたければhandler-caseやhandler-bindを使います。e))))エラーの無視や自動リトライなどもhandler-bindでできます。"http://lisp.org"))こういった構文は安易な発想をすればマクロを使うシーンです。独自のマクロは使い方を覚えてもらう必要があり学習コストがかかります。一方でhandler-bindやhandler-caseは言語仕様の機能なので誰でも使えます。ここにも11日目でも取り上げたマクロレス思想の一端が見られます。Drakmaの微妙な不具合Dexadorを作っている過程でいくつか不具合も出ました。新しいプロダクトだから仕方ありませんね。ところでDrakmaはどうやっているのだろう。試してみると同じ不具合があった、というようなことも多くありました。結果的にDrakmaのあまり知られていない微妙な不具合をいくつか知っています。tでストリームで受け取るとかなり面倒なことになるな。2015年7月28日twitter.comDexadorでkeep-aliveのコネクションをストリームで受け取るとブロッキングする問題が見つかって、これCHUNGAがおかしそうだけどDrakmaはどうやってんだ、って思って試したらDrakmaも同じ挙動だった。2015年8月27日twitter.com「Drakmaでもコネクション再利用できるよ」なんて言ってくる人なんて今までいませんでしたけど、いたとしたらドキュメントを読んだだけで使ったことがない人なのでしょうね。おわりにhttps://github.com/fukamachi/dexadorhttp://quickdocs.org/dexador/明日のアドベントカレンダーは21日目、たぶんLackについてです。