Google Gears + appengine = client-side grid computing?

これは悪くない案だと思うんだけどなあ。
Google Groups

GAEは常駐プロセスと定期起動イベント(cron)を許可しておらず、一回のアクセスで行われる処理に数秒以上かかる場合は処理を中断させるという仕様になっています。なので、例えば以下のようなアプリケーションはGAEでは書けないはず。
・ターン制のゲーム(箱庭諸島とか。ターン更新時に処理がまとめて行われるため、GAE的にアウト)
・検索エンジン(のクローラ。常駐プロセスが必要)
・BOT(常駐プロセスか定期起動イベントが必要)
定期起動イベントに関してはcronが使える他のサーバからキックしてやれば良いのですが、一回あたりの処理時間が長くなりがちなものや常駐プロセスがないとどうしようもないものに関しては、普通の方法では実装できそうにないです。

で、出てくるのがこの"Google Gears + appengine = client-side grid computing"というアイデア。
重い処理はクライアント側に行わせてしまって、その結果だけGAEサーバで使おうよ、というものです。クライアント側にはGearsやFlash等で書かれた分散処理を用意しておいて、クライアント側の事情が許す限りサーバ側からデータを送って、クライアント側で作成された処理結果をサーバ側にもらってくるという感じ。

冒頭に挙げたスレッドではけちょんけちょんに書かれているのですが、
・Gearsは遅いよ→Flash使えばええやん。FlashのVM(AVM+, Tamarin)は早いよ。
・分散処理を実行させておくメリットがユーザには存在しないよ→メリットを作ればええねん。ゲームの処理を分散させるんだったら、計算負荷を負担してくるユーザに対しなんらかの賞与を与えるとか。
・別にGAEと関係ないんじゃない?→GAEは常駐プロセスを走らせられないけど、クライアント側の協力があれば擬似的に常駐プロセスを走らせることができるんじゃない?
というわけで、元になるアイデアは依然として悪くないんじゃないかと。
まあ、スレ主がSETI@HOMEとかMap-Reduceとか割と見当違いな方向性のものを書いてるから、反応が良くなかったんじゃないかという気もしなくはない。

皆様におかれましては、どうお考えになられますでしょうか。

ちなみに、ここまでスレ主を擁護してるのは、既にこの案に基づいたものを書きつつあるからなんですが……同じことを考える人もいるもんだなあ。
いまGearsMonkeyについて悩んでるところです。