パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Google、Web上の文書作成兼表計算サービスを提供開始」記事へのコメント

  • 一人だけが編集する文書だと、あまりメリットを感じられないかもしれません。

    なにより便利なのは、ひとつの文書を複数人がリアルタイムに同時に編集するときです。
    他人の変更をリアルタイムで知ることができるのは極めて強力であり、Webならではです。

    Wordでつくった文書をメールで送り、修正してまたメールで送り、また修正してメールで送る、、実はお互いに修正していてマージが大変、、、というこれまでの行為がいかに原始的だったかと思い知らされます。
    • by Anonymous Coward on 2006年10月13日 0時04分 (#1036471)
      >他人の変更をリアルタイムで知ることができるのは極めて強力であり、Webならではです。

      そんな馬鹿な。リアルタイムで他のユーザが、いやそれどころかサーバが状態変化を通知するのは、ステートレスかつクライアントからの一方通行たるWebアプリの最も苦手とするところですよ。
      Webでそれをやるには昔のチャットのように頻繁にリクエストを投げるか、もしくは更新リクエストを受け付けたらレスポンスを返すのをわざと遅延させる、なんていう小細工が絶対に必要になります。

      そういうのが得意なのはWebが登場する前のいわゆる「クラサバ」(Webもクラサバなのにねえ…)と呼ばれる物です。ソケット開きっ放しもよし、サーバからクライアントに更新を伝えるもよし、まさにリアルタイム向きです。

      この手の物をWebでやるメリット、それはもう散々言われてますがクライアントにソフトをインストールしなくて良いという事、それとOSを(比較的)選ばないという事、ですよ。
      親コメント
      • > もしくは更新リクエストを受け付けたらレスポンスを返すのをわざと遅延させる、なんていう小細工が絶対に必要になります。

        Google Talkはこれじゃなかったかな?

        非同期でリクエストを投げて、応答を返すタイミングをサーバサイドで制御することで(サーバ側でイベントがあるまで応答を遅らせる)、
        「サーバから状態変化を知らせる」ような動きを実現していると。小細工といえば小細工ですが。

        今回のブツが同じ仕組みかどうかは分かりません。
        親コメント
      • by Anonymous Coward on 2006年10月13日 9時00分 (#1036574)
        ‥という意味だろうに、元発言は。
        どういう作りだろうがそんなもん関係無い、実現している機能に意味がある、という風な。

        Webアプリの同時利用だと距離依存しないで済むのだから。
        親コメント
        • その通り。それこそがWebの醍醐味であり、
          リアルタイムどうこうは全くお門違い。

          と元コメントは指摘してるだけなのに何でこう一見反論のような、
          でも反論になってないレスが幾つも付くのか不思議だ。
          別に煽り口調でもないし、常識的な事を羅列してるだけなのになあ。
          • > と元コメントは指摘してるだけなのに何でこう一見反論のような、
            > でも反論になってないレスが幾つも付くのか不思議だ。
            論点が完全にずれているから。
            違う視点から見たWebの評価を、違う意味でのリアルタイムに使ったせいで混乱してんだよ。

            大元のコメント・・・ユーザにとってのリアルタイムさユーザが利用しやすい から、Webならでは
            指摘の論拠・・・Webは 技術的な意味でのリアルタイム通信実装者が実現しにくい

            > リアルタイムどうこうは全くお門違い。
            の指摘の方がお門違いだということに気付け。

            #って、もう見てないか
            • >大元のコメント・・・ユーザにとってのリアルタイムさ を ユーザが利用しやすい から、Webならでは

              嘘つけ。ユーザにとってのリアルタイムさは技術に依存しない。UIに依存する。
              そういう意味でもWebのリアルタイムさは必ず他の一般的なクラサバ系アプリに劣る。
              AjaxとDHTMLをふんだんに使って漸く追いついてきたが、それでもまだまだブラウザの制約に縛られている。

              そもそも”Webよりもユーザにとってのリアルタイムさ をユーザが利用しにくい”仕組みってどんなのよ?
              • >嘘つけ。ユーザにとってのリアルタイムさは技術に依存しない。UIに依存する。
                >そういう意味でもWebのリアルタイムさは必ず他の一般的なクラサバ系アプリに劣る。
                >AjaxとDHTMLをふんだんに使って漸く追いついてきたが、それでもまだまだブラウザの制約に縛られている。
                だから、何でクラサバ構成と比較するんだよ。クラサバ側には比較対照になるUIすらないだろ。
                …じゃなくて、Webとクラサバ構成との比較結果を使おうとしてるのがおかしいっていってるんだよ。

                WebベースにOfficeソフトを作ったから、リアルタイムさがあるし、手軽に使える。
                ローカルアプリだったOffice
              • >クラサバ構成の方がよりリアルタイムで操作感が良いし、高機能って話だけなら別に異論は無い。

                これで話終わっとるが一応各種突っ込み。

                >だから、何でクラサバ構成と比較するんだよ。クラサバ側には比較対照になるUIすらないだろ。

                有るか無いかは関係ない。実現方法がWebかそれ以外かの比較なんだから。

                >WebベースにOfficeソフトを作ったから、リアルタイムさがあるし、手軽に使える。
                >ローカルアプリだったOfficeソフトと比べて、ユーザにとってのリアルタイムさがあるかないかの話なんだよ。

                そう書いてあれば何も突っ込みどころは無かったね。

                >クラサバ構成とWeb
              • >ローカルアプリだったOfficeソフトと比べて、ユーザにとってのリアルタイムさがあるかないかの話なんだよ。

                べつに、ローカルな伝統的Officeに、リアルタイム同期するためのプラグインでも、入れればいいのでは?

                #サーバが必要だというなら、それも開発すればいいだけのこと。それをイントラなりInternetなりに置けばいい。1つの文書を共有したい範囲の人らが1つのサーバを共有すればいいのだから、Googleみたいに世界全体を一手に引き受ける必要はない。
                ##でもサーバ方式じゃなくP2Pのほうがお洒落な気もするぞ。

                もちろんこれは、もしそういうプラグインが作れるならばの話だが、べつに出来ないと決まったわけでもあるまい。

                どうやりゃ出来るかなあ?
                MSOffice(OLE)だと、今編集してるデータの部分要素が変更されたかどうかをWaitForObjectしといて(出来る。。。んだったよね?)、変更があったらそれをP2Pなりサーバなりに投げる。そんな感じで出来ないかな?
      • by Anonymous Coward on 2006年10月14日 11時38分 (#1037130)
        Webならでは、というよりは、ネットならでは、と言いたかったのでは?
        親コメント
      • >Webでそれをやるには昔のチャットのように頻繁にリクエストを投げるか、もしくは更新リクエストを受け付けたらレスポンスを返すのをわざと遅延させる、なんていう小細工が絶対に必要になります。

        Ajaxはまさにそこの代替案です。
        非同期通信とはそういうものです。

        ただ、個人的には環境を選ぶDHTMLなどはWebの退化だと思っているのであまり喜ばしく思ってませんが。
        • by Anonymous Coward on 2006年10月13日 0時43分 (#1036504)
          >Ajaxはまさにそこの代替案です。
          >非同期通信とはそういうものです。

          全然違います。Ajaxが実現したのはあくまで(Webアプリの致命的な弱点であった)『リクエストと画面の全書き換え』を非同期化した、という事であって、リアルタイムどうのこうのとは全く無関係です。Ajaxを使おうが、「頻繁にリクエストを投げるか、レスポンスを遅延させる」のが必須である事は変わりません。
          と謳っているCometでさえ
          社長 江島健太郎氏によるとCometは「コネクション張りっぱなし方式」。技術詳細は江島氏のブログが詳しいが、基本はクライアントが発行したHTTPリクエストをサーバが受け入れたままにして(セッションをつなぎっぱなしにして)、メッセージ投稿など外部からサーバに対してイベントがあった場合に、サーバがクライアントに対してメッセージを送信する。
          なんて言ってる始末。まさに私が最初に挙げた小細工そのままです。そして、Jetty 6を採用することで負荷の問題を回避している、とも言っています。お分かりですね。ここまでやらないとWebでリアルタイムな更新は実現できないのです。よって、改めて

          「リアルタイムはWebならでは、なんて事は有り得ない」

          と主張します。
          親コメント
          • んー、ConnectiveChat [g2.ngw.jp] みたいなのが動いているのを見るにつけ、その小細工とやらでうまく動いているんであればまぁ、別にいいんじゃない? とか思うわけですが。。。

            無論、Web を使う最大のメリットは、UA が既に十分普及していることのみなのであって、リアルタイム性を追及する方法として、Web とは別のアプリを用意するという方法の方が Ajax on web で作るより現実的であるようなシチュエーションというのはあるだろう、というのは確かだとは思いますが。

            でも現状の Web で十分な程度のリアルタイム性しか必要ないんだったら、今から専用アプリばら撒いて普及させるよりは、Web 上で動かした方が客は釣れそう、って思うよなぁ。。。

            --
            むらちより/あい/をこめて。
            親コメント
            • >> んー、ConnectiveChat みたいなのが動いているのを見るにつけ、その小細工とやらでうまく動いているんであればまぁ、別にいいんじゃない? とか思うわけですが。。。

              そうですよね。よく似た話として、 UNIX 系のような OS はリアルタイムなアプリには向かない、というのがありましたが、やってみればそこそこ使える。また、そういう要求がでてくれば realtime linux のようなものも出てくる。

              メモリが少なくかつ高価な計算機を複数人で共有していたころは、統合環境である emacs を複数開けるべきではない、ということを先輩から指導され、メイルもニュースもプログラム開発も論文作成も1つのemacsでやってたりしましたが、メモリ食いまくりアプリが溢れる昨今、emacs なんてなんぼでも立ち上げて使うようになってきている。

              「そもそも」論は、技術の進歩が激しい分野では、虚しいことが多い。。。

              要はニーズのある使われ方で使えればいいんですよ。
              親コメント
          • by Anonymous Coward on 2006年10月13日 3時04分 (#1036539)
            standaloneのオフィスアプリケーションに対するwebアプリ、という話だったのに、勝手に専用クライアントvsブラウザベースアプリの話にすりかえるな。何興奮してるの?
            親コメント
        • かつての UA ベンダー主導で提案されてきた DHTML の時代は確かに過去の産物だ。今は Web 開発者が主導でアイデアを提案し、環境の方がそれに合わせるべく標準化を進めている。いずれ、「DHTML は環境を選ぶ」という考え方自体が過去のものへとなってゆく。

          ただ、個人的には環境を選ぶDHTMLなどはWebの退化だと思っているのであまり喜ばしく思ってませんが。

          そう悲観するほど、未来は暗くはありませんよ。;)

          --
          むらちより/あい/をこめて。
          親コメント
      • > 小細工が絶対に必要になります。
        その程度が小細工なら、ディスクにデータを退避させて実メモリ以上のデータを扱ったり、プロセスを高速に切り替えて1CPUで同時に複数のタスクを実行したり、複数のディスク上に一つのファイルを分散させたりといった、近代的な情報工学の成果はみんな小細工ですね。
        • >その程度が小細工なら ~ 近代的な情報工学の成果はみんな小細工ですね。

          はぁ。まさかもう付かないよな、と思ってた類のレスが結局ついた。「小細工」なんて言葉はどうでも良いのですよ。何なら「工夫」とか「近代的な情報工学の成果」と言い直しますよ?結論は同じです。そのような近代的な情報工学の成果が必要になる時点で「ならでは」ではありません、と。
          他に解として適切なアーキテクチャがあるのに、寧ろ苦手な分野であるにもかかわらず「Webならでは」とあたかも得意分野であるかのようにミスリードしている所に文句をつけているのです。

          お尋ねしますが、ある命題Xを実現するために「ディスクにデータを退避させて実メモリ以上のデータを扱ったり、プロセスを高速に切り替えて1CPUで同時に複数のタスクを実行したり、複数のディスク上に一つのファイルを分散させたりといった、近代的な情報工学の成果」が必要なアーキテクチャAがあったとして、逆にそれらを必要としないBが存在する場合に、「XはAならでは」なんて言います?yesならば、もう私から申し上げられる事は何も有りません。
          • 元の人:「Webならでは」というのが間違い。
            次の人:それへの反論ののはずなのに、「Webアプリの最も苦手とするところ」という的外れ(別件)の指摘をしてるのが間違い。

            ーーー

            >成果が必要になる時点で「ならでは」ではありません

            違います。
            代替実装が存在していれば「「ならでは」ではありません」と言えます。
            対象(この場合はWeb)の中身がどうなっているか?なんてのは無関係な話です。

            つまり、

            >アーキテクチャAがあったとして、逆にそれらを必要としないBが存在する場合に、「XはAならでは」なんて言います?
        • うーん、元発言者の意図はどうか知りませんが、普通のプログラマの感覚での「小細工」とは、不細工な仕組みを作るということだと思われますから、

          > ディスクにデータを退避させて実メモリ以上のデータを扱ったり、
          > プロセスを高速に切り替えて1CPUで同時に複数のタスクを実行したり、

          > 複数のディスク上に一つのファイルを分散させたりといった

          という、ちゃんとレイヤ分けすれば、利用者(プログラマ)から隠蔽できるような仕組みは小細工だとは思いません。

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

処理中...