#結局kahua-spvrはdaemontoolsで動かして起動オプションで-l-を付ければいいってことか。kahua-cgiはそれじゃだめなので何らかの手段で分割するしかない
#Apacheのログと混ざっていいならkahua.cgiのログをstderrに吐かせるって手はあるかも。
#ああでも通常のログがerror.logに入るのは気持ち悪いか。
#kahua.cgiはやっぱり現状のKahuaの癌のひとつだなぁ
#やることをうんと限定して、Apacheモジュール化するか、諦めて他のブリッジングプロトコル(ajpとか)を喋るようにした方がいいのかな
#あるいは、いっそkahua-httpdをもっと強化して、リバースプロキシを使うようにするとか
#そうですねぇ。モジュール化は色々面倒 (書くだけでなく、インストールとかそれに伴うapacheのコンフィグレーションとか) なので、黙ってても大抵入ってるようなapacheのモジュールが流用できたらベストだと思う。ajpは今ざっとみたところそんなに面倒なプロトコルじゃなさそうだけど、大抵入ってるもんかな?
#リバースプロキシもありだと思うけどサイトごとに色々事情があるので、オプションのひとつとしとくのが無難かと。
#そんで、リバースプロキシと、既存のモジュールによるブリッジ、という選択肢が用意できたら、cgiのサポートは落としてもいいかもね。
#(裏技として、mod_perlみたいにほぼ必ず入ってて使えそうなモジュールを使って、(mod_perlなら)perlでkahua.cgi相当のブリッジを書いてしまう、という手を考えたことはあった)
#どうなんでしょうね
#ひところだと、Linux distroはデフォルトが「全部盛り」みたいな感じだったけど
#最近はセキュリティの兼ね合いもあって、mod_perlなんかは明示して入れないと入らなかったりするんじゃないかなぁ
#ちなみにajpブリッジは雛形をyusei君が作ってくれてるんですが
#すでに3年以上放置してます
#人でなし >おれ
#そういえば、mod_lispってのもあって、HTTP<->S式ブリッジなんだろうと思ってみてみたら、中途半端な行指向プロトコルでがっかりした記憶が
#ajpも今ひとつちゃんとサポートされてる感がなくて、積極的に組み込む気が起きないんですよね
#たいていの環境にはデフォルトでは入ってないと思うし
#うん、mod_lispはいまいち。でも自作するとして、まあS式ベースにはするだろうけど耐障害性とかエラーハンドリングとかですごく良いものを作れるリソースがあるとも思えない。
#最近のホスティング環境だと、httpdもapache以外に色々選択肢が用意されてるし、アプリケーションサーバもリバースプロキシでやるのが主流になってるのかなあ。
#Railsとかってどういう環境を想定してるんだろ。
#このへんは、レガシー環境に配慮して余分なコードを抱えるよりも、主流の環境に乗っかっちゃって楽をする方が正しい気がする。
#やはりkahua-httpdが王道な気が。mod_kahuaがあってもいいけど。zope-httpdのソースを読んだら、ApacheソースをPythonに直訳したような処理があった。物量作戦ですね
#＞Railsとかってどういう環境を想定してるんだろ
#最近は巨大サイト以外は passenger(mod_rails)が良く使われてます。これは FastCGIをモダンにした感じのものです。
#巨大サイトはフロントは apacheまたはnginxで reverse proxy + mod_balancer し、Railsアプリは mongrel/thin などのアプリケーションサーバーで動いてます。
#それからRailsを始め最近のRuby製のフレームワークは PythonのWSGIにインスパイアされた Rack という ミドルウエア/仕様の上に構築されています。
#そして、passenger, mongrel,thin... などのサーバーはRack I/F をサポートしています。
#ちなみに Perl でも miyagawa さんとかが中心になって WSGI, Rack にインスパイア された Plack が作られています。
#ありがとうございます >Yuumi3 ということはみんな(1)apache moduleのブリッジとrevese proxyをケースによって使い分けてる (2)で、その使い分けを抽象化しちゃうミドルウェアが開発されてる、っていう感じかな。
#mod_kahuaをciseで書けたら嬉しい(かも)
#結局のところ、HTTPから各フレームワーク/アプリケーションサーバ独自のプロトコルへの変換をどこのレイヤでやるか、という問題なのかな
#KahuaのS式プロトコルは美しいしLispyなんだけど、S式プロトコルを使うメリットが今ひとつ見え難い
#書けなくはないけど (unofficialなので互換性が保たれないリスクをとれるなら)、ciseを使っても文法がS式になるだけでやれることは基本的にCと同じですよ
#で、AJPブリッジに今ひとつ乗り切れない理由のひとつが、HTTP<->AJP<->Kahua Protocolという3段変換が「無駄じゃね?」という疑問が拭えないから
#というか「ランタイムはCto
#「ランタイムはCと同じ」という方がいいか。構文的にはいくらでもマクロで抽象化できるので。
#Apacheも、mod_fugahogeを書くヘルパ的なツールを用意してるんですよね
#どっちを使う方が楽なんだろう
#ajpに限らず既存のブリッジを使うなら、kahua-spvrの方で直接そのプロトコルを解釈してkahuaのルーチンを呼ぶようにするのがいいんじゃないかな。つまりS式プロトコルを受ける部分とajpを受ける部分は同列に並ぶ。
#なるほど
#kahua-httpdと並ぶ形を想定してました
#kahua-ajpdみたいな感じ
#実際にS式プロトコルを解釈するのはワーカ(kahua-server)なのですが、そこがマルチプロトコル対応するとかなり煩雑になる気がするなぁ
#あっそうか。spvrだけじゃなくworkerもいじらなくちゃならないのを忘れてた。
#ってことはajp <-> S式プロトコルってレイヤが(daemonでなくて、ライブラリの形でも)どっかには入るってことかぁ。
#むー、そうするとアーキテクチャ的にはmod_kahuaみたいなものの方がはるかに綺麗だなあ。
#現状だと、spvrが解釈するのはS式プロトコルのgsidとcsidだけですね
#ディスパッチ先のワーカを決めたら、来たS式をまるっとワーカに投げるだけ
#そう思います >mod_kahuaの方が綺麗
#ブリッジをHTTP<->S式変換層と位置づけるとそうなる
#ここ1ヶ月でのべ250km以上走ったんだけど(自己最長)、体重が63kgから微動だにしない
#体脂肪率も16%台前半が15%台後半になっただけ
#エネルギーの出入りがちょうど平衡状態になってるのでは。つまりその分食ってる、とか。
#走っても痩せない身体できあがり(笑)
#はい
#学生時代並みに食べてます
#でも、前回200km超/月の走行距離だった2008/05の記録を見ると、体重が2kg以上落ちてる
#あの時もかなりがっつり食べてたはずなのに
##ギターにUSB I/Fが組み込まれる時代なのだなぁ
#欲しくないけど(笑)
#testing bindings in #<module gauche.record> ... ERROR: symbols referenced but not defined: %make-record(rtd-constructor), %make-recordv(rtd-constructor), %record-set!(rtd-mutator), %record-ref(rtd-accessor)
#make maintainer-cleanしてからビルドしても出た
#あーわかった
#src/libgauche-0.9.dylibは作られるのだけど,
#libgauche.dylibが作られず
#かつsrc/goshはlibgauche.dylibをリンクしているので
#インストール済みの古いlibgauche.dylib
#が使われちゃうんだ
#srcで、ln -s libgauche-0.9.dylib libgauche.dylib ってやってからmake checkすれば通る
#あれ? configure後のsrc/Makefile中の、gosh_LDADDの定義はどうなってますか?
#gosh_LDADD = -lgauche-0.9
#になるはずなんで、libgauche-0.9.dylibをリンクすると思うんだけどなあ。
#あ、ヘルパースクリプトlink-dylib中でinstall_nameを指定してるのがまずいのかな。
#src/link-dylibを次のものに置き換えてやってみてください > (び)
##!/bin/sh
# Helper script to handle building libgauche.dylib on MacOSX
# Assumes $TARGETLIB is set by the caller.
CCLD=$1
shift
if echo "$*" | grep dynamiclib > /dev/null 2>&1 ; then
libname=`echo "$*" | sed -n 's/.*-lgauche-\([0-9.]*\).*/libgauche-\1/p'`
$CCLD -install_name ${TARGETLIB}/${libname}.dylib "$@"
else
$CCLD "$@"
fi 
Gauche > Archives > 2010/01/15