ページへ戻る

− Links

 印刷 

design005 :: OSASK計画

osaskwiki:design005

ページ内コンテンツ
  • ネットワークに対する考察
      • (0) このシリーズについて
      • (1)
      • (2)
      • (3)
      • (4)
  • こめんと欄

ネットワークに対する考察 anchor.png[1]

Page Top

(0) このシリーズについて anchor.png[4]

  • これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。
  • ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。
  • 基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLやimpressions[5]を活用してもらうほうがいいと思う。
Page Top

(1) anchor.png[6]

  • 2008.10.15のNHKのクローズアップ現代「新情報革命"クラウド"の衝撃 No.2644」を見た。これはnetwork_good[3]の続きを考えるにはいいテーマだと思う。
Page Top

(2) anchor.png[7]

  • なるほどこれはすごいと思った。いろいろ問題点は指摘されていたけど、それはどちらかといえば、自社でシステムを開発するかもしくは買い取って、それを自社のサーバーで運営すれば解決できる問題だと思った。つまり問題はPCがネットワーク端末に成り下がったことによるものではないのだ。だから番組内で指摘されていた各種の問題はこのページでは無視することにする。
  • 番組の内容は、salesforce社のシステムを使うことで会社の営業の効率が格段に上がるというものだった。ようするにこのシステムには効率的に営業をやるためのノウハウが大量に詰まっており、このシステムの助言に従ってセールスをすれば同じ時間や手間をかけてもより多額の商談を成立させることができるし、その上セールスマンの営業成績も管理できるということだった。・・・僕の率直な印象としては、仮に聖徳太子みたいな天才的な営業マネージャがいて、その人に各セールスマンが電話で営業の近況を報告し、また頻繁に営業アドバイスを受けていたとしよう。このようなスーパーな営業マネージャの作業をsalesforce社に外注している感じだ。
Page Top

(3) anchor.png[8]

  • ネットワークである必要性はあるのかというと、これはある。どんな代替法を検討するにしても、とにかく複数の社員がほぼ瞬時にデータを共有する必要があるし、それにはネットワーク上のデータベースが一番いいだろう。またただのデータベースではなく、PCとの交信量が最低限になるように工夫したサーバプログラムならなおさらいいだろう。だからこのようなシステムを作るためにネットワークが使うことは目的にかなっていると思う。
Page Top

(4) anchor.png[9]

  • これをもっとうまくできないものかと自分なりに考えた。番組を見ているとPCへはHTMLか何かの情報を送っているようだったけど(ページのつくりの印象だけで判断したので違う可能性も高い)、これは果たして最善だろうか。まあ確かにHTMLで済みそうな内容だったからこれでいいのかもしれないし、HTMLならテキストデータなので帯域の消費はかなり押さえられる。でも一部グラフが出ていたりもした。この部分はきっとPNGかなにかだろう。これは帯域的に最善ではない。最善なのはグラフを書くのに必要な数値データだけを送ることだ。次善はグラフを描画するために円弧描画命令や塗りつぶし命令などのテキストデータを送ることだろうか。
  • 仮にHTMLを送っているにしても、そもそもページをリフレッシュするたびにいつも<HTML>みたいなタグを送るのは無駄だ。むしろ先に送った内容との差分を送るくらいの方法がいいくらいだし、もっと言えばそれぞれのサイトにはそれぞれのサイトにあった(つまり可変部分だけの)送信方法があっていいと思う。テキストで送る必要すらなく、バイナリでもいいだろう。つまりこれはサイトごとに独自ブラウザを作れといっているのに等しい。なかなかに強引だ。
  • それで考えたのだけど、こういう仕組みはどうだろう。まずすべてのサイトはjavaアプレット化する(別にjavaアプレットである必然性はないのでそれに類する別の手法でもいい)。もしくは非常に細かいデータタイプ記述子がサイトにあって、その記述子からそのサイトの情報を見るためのjavaアプレットの位置が特定できるとする。このjavaアプレット名はそのアプレットのビルド番号みたいなものも含んでいるので、アプレットが少しでもバージョンアップすれば別物と解釈される。また互換性も把握していて、上位互換のあるアプレットをキャッシュに持っているのならわざわざ古いバージョンを持ってきたりはしない。
  • そしてクライアント側のPCは、アプレットをキャッシュする(キャッシュ不許可ではない限り)。これで毎回アプレットのダウンロードに時間が食われることはないし、JIT結果もキャッシュしておくことだってできる。そしてアプレットは帯域を少なくできるように最適化された効率の良いページデータ等をサイトから読み込み(もちろんこれもキャッシュが効くのでキャッシュが使えるときはそれを使い)、表示する。これならクライアントPC内のHTMLキャッシュも用量が小さくなりたくさんを小容量でためられるようになる(まあもはやHTML以外の形式になってしまっているのでこの言い方は適切ではないけど)。
  • アプレット側にレンダリングをやらせればより柔軟に表示できるだろう。むしろこの方法ならブラウザのレンダリングエンジンはほとんど要らなくなりそうだ。

  • これにオフラインモードを付ける事だってできる。つまりネットワークのトラブルなどによって最新のアプレットやデータを取り込めない場合、というかそもそもサイト上のものが更新されているのかどうか分からない時に、キャッシュのものをとりあえずそのまま使うというものだ。でもこれも限界があって、サイト上のサーバに問い合わせて表示内容を取得するタイプのアプレットだとやっぱりうまくいかない。でもこれはどうしようもないので、これについてはネットワークがダウンしているときにはあきらめるしかない。むしろ各アプレットがオフラインモード時にどうするかまで含めて記述していてほしいと思う。
Page Top

こめんと欄 anchor.png[10]

  • AjaxとAdobe FlashとJava Appletは機能が重なっている部分が多いからもったいないかも。 -- M59 2008-10-16 (木) 17:25:26
  • 確かにそれはあるかも。でもそれはもったいないというよりは競争関係にあって、お互いに改良ラッシュになっていていいことなんじゃないかな? -- K[2] 2008-10-16 (木) 18:52:36

Last-modified: 2009-11-21 (土) 00:00:00 (JST) (319d) by k-tan