#1. spvrとkeyservを廃してappserverが直接HTTPをしゃべる
#2. プレゼンテーション層とロジック層との分離
#3. sandboxの廃止
#というのがshiroさんのアイディアで
#1.の派生としてcgi bridge廃止もありますね。
#はい。それは異存ないです。
#今時だと高速なリバースプロキシを前に立てて、というパターンが定着してますしね。
#spvrを廃する時に障害になるのは、無名継続の扱いですかね。
#appserverが一つだけなら問題無いですよね?
#appserverがシングルプロセスなら問題にはならないですけど、スケールしなさそう。
#はい。シングルプロセス内なら問題ないです。
#その場合は自動的にkeyservも廃止。単なるプロセス内部の継続を生成URLにマッピングするだけでとてもシンプルになる。
#やっぱりスケールの問題があるかぁ。けどバックエンドのプロセス間でメッセージをやりとりするのが面倒くさい…
#keyservについては、appserver立ち上げ直してもログインセッションが維持されるのが便利だったりするんですが、そういうのはmemcachedでもできるからそれでいいかなと。
#確かにそうですね。memcachedのプロトコルをしゃべるなら、memcachedだけじゃなくてpersistentなストレージエンジンも使えるし。
#実際のところ、スケールが問題になるのって8コアとか16コアのマシン1台でマルチスレッドで走らせてるだけじゃやっぱり足りなくって複数マシンに展開したい、とかそういう場合ですよね?
#はい。
#リバースプロキシ前提なら、無名継続のprefixをマシンごとに決めておけばapacheで振り分けられるんじゃなかろうか。
#個人的にはマルチスレッドをrobustに書くのがしんどいので、greenthread + マルチプロセスにしておきたい、とは思ってますが。
#あと、無名継続をがしがし使うケースって個人的には(意図的にそうしなければ)そこまで多くないので、kahua-call-with-current-contextまでだったらkeyservに追い出せてマルチプロセスで処理できるなぁ、とも思ってたり。
#ふむ。それならイベントループ回す形ですか > greenthread+マルチプロセス。同じプロセスイメージがspawnするだで、各自が完全に独立してる (データ共有ばバックエンドDBのみ) っていうなら確かにシンプルかも。
#無名継続のところだけURLの工夫+リバースプロキシで頑張る、で何とかできれば、それが一番シンプルだし、パフォーマンスも稼げるかなぁ、と。
#あと、個人的に必要だと思ってるのは、コンテキストや無名継続の強制破棄機能ですかね。戻れちゃ困る場合に、ばさっと捨てられる機能が欲しい。
#はい。メモリコントロールの点でも重要だと思います ＞破棄機能。継続に動的エクステントを導入するというのは可能かもしれない。
#イベントディスパッチのライブラリって最近はどれが定番? libev? libuvってのもあるよね。
#libeventよりはlibevの方が性能がいい、という話くらいしか知らないです(仕事でlibev使ってます)。libuvは使ったことないです。
#libuvって、node.js由来なのか...
#性能いいのかな。
#oodb層は何か変えたいところある? 個人的には今のでもそこそこ満足しているんだけど、OOにこだわりが無いので実はわざわざ永続オブジェクトを持たなくてもいいかなって気がしてきている (永続的なマップさえあれば)。
#クエリ言語までいかなくても、ある程度問い合わせ機能は欲しいですね。getとscanしかない、というのは潔いけど、特にWeb系のアプリではしんどいときもあるので(ページネーションとか)。
#あと、楽観ロックは欲しいかも。
#そこいら辺が実は、バックエンドに既存のKVS(系のストレージエンジン)を使って楽したいなぁと思ってるところなんですよね。
#ふむ。クエリは確かに再発明するのはしんどいし無駄でもあるなあ。key-value storeのクエリ言語ってどのくらいリッチなんだろ。(NoSQLはAllegroGraphしか使ったことない; あれはSparqlが使えてものすご強力)
#いや、あれと比べちゃうのはちょっとwww
#基本、getとscanしかないんですが、サーバサイドでmap/reduce相当の処理を書ける、というのが流行りでしょうか。RiakだとJavaScript、Redisはmap/reduceまで強力ではないですが、Luaで絞り込みの条件書けたかな。
#なるほど。汎用言語(のサブセット)をサーバサイドで処理って方向ならわりと何でもありですね。
#あとはセカンダリインデックスをサポートして何とかするとか。
#分散系のストレージは、やはりscan系の範囲検索の実現にはみんな苦労してるみたいです。
#とりあえず有りものがあるコンポーネントは有りものを使ってどこまでシンブルに作れるかやってみるかな。もはや現在のKahuaの形を留めないかもしれないけれど、気分的にはKahuaの延長ということでやってみたくはある。
#シンプル。なんでブになっちゃったんだろ。ローマ字入力なのに。
#プレゼンとロジックの分離について簡単にメモっとく。今のKahuaも一応アプリロジックとレンダリングは分かれてるんだけど、アプリロジックの方でかなりhtmlべったりに書くようになってる(そうでない書き方もやろうと思えばできるわけだけど、サンプルがhtmlべったりになっちゃったからなあ)。アプリロジックはむしろ Map -> Map みたいなものすごくシンプルな形式にして、レンダラがSXMLテンプレートに出力Mapを流し込んでSXMLを作るという形。
#いちおう、XMLのテンプレート読んで埋込む機構はあるんですが、いかにもしょぼいですからね。
#id指定してまるっと置き換えるだけだもんなぁ。属性だけ設定するとかできないし。
#.Netのコードビハインドみたいに、デザイナーがDream Weaverで作ったHTMLwo
#をそのままテンプレートとして無変更で使えるのが理想だなーと思ってたんですが、なかなかそこまで手が出なかった。
Gauche > Archives > 2013/06/30