CALENDAR
Sun Mon Tue Wed Thu Fri Sat
    123
45678910
11121314151617
18192021222324
25262728293031
<< August 2019 >>
本家STORY FACTサイト
NEW ENTRIES
CATEGORIES
RECENT COMMENTS
  •  『マネーショート』を観た!
    萬太郎 (10/03)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    hikali (05/08)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    マイケル村田 (05/04)
  • GB解析 -NG- ウィザードリィ3 ダイヤモンドの騎士 橋爪さんですね・・・
    hikali (03/29)
  • GB解析 -NG- ウィザードリィ3 ダイヤモンドの騎士 橋爪さんですね・・・
    マイケル村田 (03/25)
  • GB解析 -NG- ルパン三世/暁の第三帝国 良作なエンターテイメント
    hikali (01/09)
  • GB解析 -NG- ルパン三世/暁の第三帝国 良作なエンターテイメント
    マイケル村田 (01/06)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    hikali (11/24)
  • GB解析 -NG- 邪聖剣ネクロマンサー イシュメリアの悪夢 やったことあるんだよね・・・
    マイケル村田 (11/21)
  • GB解析 -NG- 新・鬼ヶ島 暗黒の化身を討て! 成功した理由が良く分かりました。
    hikali (06/27)
RECENT TRACKBACK
ARCHIVES
MOBILE
qrcode
LINKS
PROFILE
OTHERS
無料ブログ作成サービス JUGEM
 
管理人hikaliの開発の日々の備忘録です。
本家はこちら。
http://plaza.rakuten.co.jp/hikali/
<< [Pythonゲーム修行]泣きそうになった・・・。 | main | 浦和レッズのベストフォーメーションを考える2008(18) 【反省会】大分戦 ホーム >>
[Pythonゲーム修行] 仕様策定会議 データの受け渡しどうするか。

 うーん、困った・・・。
 困ると出てくるのが、この開発メモ。
 文字が残っているということは、困ったと言うこと。
 わかりやすい(笑)

 えーと、今困っているのは、データの受け渡し。
 Webアプリケーションというのは、基本的に、ブラウザが再描画するたびに、プログラムをはじめから立ち上げ直しているような仕組みになっている。
 逆に、たとえばわたしが書いていたPythonのプログラムは、たとえば30分ぐらい操作している間中も走り続けている。
 で、再描画すると、当然プログラム内に保持されていたメモリーがなくなってしまう。
 なので、何らかの方法で、データを受け渡してあげなければならない。

 で、これはいろいろ方法が用意されていて、一長一短がある。

 1.GETとPOST

 これはhtmlのフォームの仕様で、GETはURLにデータを埋め込んで渡す方法、POSTは非表示的にデータを送る方法(<これどういう仕様なんだろうと思ったりして・・・)。
 少なくともhtmlであるかぎり、どんな場合でも使用する事ができる。

 2.テキストデータで保存

 データをテキストデータにして、それをhtml(というかそれ相当のもの)を読み込む時に一緒に読み込む。この際、ファイル名はランダムにして、なるべくユニークにする。

 3.クッキー

 クッキーは、基本的にテキストファイルで、クライアント側に保存する。仕様上、2kまでという制限があるので、パラメータのような小さなデータのみをクッキーで管理して、大きなデータはPOSTなどで送るといった方法がとられる。

 4.セッション

 セッションは、セッションクッキーという小さなテキストファイルをブラウザ内に保存し、それをキーにして、データをサーバ側のメモリー内に保存するという仕様である。phpはこのセッションが異様に便利。なので、これまではこれを酷使してきていた・・・。Pythonはフレームワークを導入しないと使えない。なので、この選択肢が使いにくい。

 5.データベース

 セッションはメモリー内にデータを書き込むが、これをハードディスクに直に書いてしまうのがデータベースと考えるといいかも。データの永続化に適している。わたしは古い人間なので、いや、こんな一時データ管理にわざわざデータベースを使う必要があるのか、と思ってしまう。
 でも、インメモリーなデータベースで、ワークテーブル気味に使うならいいのか・・・。

 6.Ajax

 これは、まあいろいろあるのだけど、基本的に、クライアント側にあるJavaScriptでクライアントのメモリー内にデータを保持し、サーバとのデータのやりとりはXMLを使うという仕様だとわたしは理解している(<よくわかってないので、間違っていても勘弁・・・)。ブラウザに標準的に装備されている、スクリプト言語というところが非常に強力で、それがAjaxが流行っている理由とも言える。

 7.FLASH(ActionScript)

 UIをFLASHで統一している場合には有効な方法。基本的にFLASHといえども再描画すればメモリー内のデータは失われる。これは、JavaScriptでも同様なはずなんだけど、どうなっているのかなあ・・・。

 8.SheredObject(これはFLASHというか、Flexの仕様だなあ・・・。)

 これは、何というか、共有できるセッションみたいな仕様。とりあえず目下最強。
 ただし、これを実現するサーバソフト(Adobe謹製)がめちゃくちゃ高かった気がする。今はどうだかはわからない。ここまでするなら、別にデータベースで、SQLiteあたりにキリキリ働いてもらう方がいいかな、そういう方が好きかなあ、という感じ。

 9.BigTable

 これはGoogle App Engine標準のデータベース。大量のストリームを扱うのに適していて、どうもGoogle App Engineはこの永続化するデータベースを、ワークテーブル的につかえよばーかと言っているような気がする・・・。あー、うーん・・・、とりあえずGQLを習得しなければならないので、障壁は高い。


 というわけで、とりあえずはPOSTで全部データは送って、そのうちわたしのGQLのレベルが高くなってきたらBigTableをワークテーブル的に使うというのが一番いいのか・・・。基本的にBigTableはあらゆるグーグルサービス上のあらゆる動作を、永続的に保存しているはずなので、仕様としては、ここにあるすべての仕様に、力業で勝っているといえないこともない。

 うーん・・・。なるほど・・・。

 ちなみに、Google GearsやAdobe AIRは、クライアント側に、SQLiteを標準装備させる仕様で、これをワークテーブル的に使う。結局、方向はデータベースなんだね・・・。なるほど。

 まあ、こういう検討ができるというのはそれなりに広範な知識を持っていると言うことか・・・。



| - | 00:10 | comments(0) | trackbacks(0) |









http://blog.story-fact.com/trackback/973287