2009/05/29 米グーグルは5月28日、米国サンフランシスコで開催中のイベント「Google I/O 2009」で、まったく新しいメッセージングおよびコラボレーションのためのプラットフォーム、「Google Wave」を発表した。同日、開発者向け早期プレビューとして公開。限定的にアカウントを発行して、外部の意見を取り入れながら開発を進める。年内にも一般向けサービスを公開し、それに続いてサーバの実装も順次、Apache2.0ライセンスのもとでオープンソースで公開していく予定だという。 プロジェクトリーダーで、Google Waveの基調講演でデモンストレーションを行ったラース・ラスムセン氏は、Google Waveは「3つのP」からなると説明する。 Google Waveのプロジェクトリーダー、ラース・ラスムセン（Lars Rasmussen）氏は、Google Waveは「3つのP」
Cometに関するrx7のブックマーク (13)
-
rx7 2009/05/30
-
WebベースのチャットシステムをCometで·Comets MOONGIFT
先日、Lingrのサービス停止が発表された。ビジネス的には難しい面もあったが、技術的には興味深いものだった。特にCometについては、Lingrではじめて知ったという人も多かったのではないだろうか。 Rubyで実装されたComet Webブラウザベースながら擬似的な持続的接続を可能にするCometを手軽に体験してみたい、という方はCometsを試そう。 今回紹介するフリーウェアはComets、RubyベースのCometエンジンだ。ソースコードは公開されているがライセンスは明記されていなかったのでご注意いただきたい。 はじめにお断りしておくと、Cometsはまだ完全な実装ではないようで途中で接続が切れてしまう。最近話題のSinatraをフレームワークに用いており、アプリケーションサーバはMongrelを使っている。 Firefoxから アプリケーションとしてはベーシックなチャットアプリケーシ
-
梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート:Kenn's Clairvoyance
先週末に予定されていたJTPA企画の梅田さん主催オンラインサロンですが、会場に多くの人が集まるにつれてLingrが重くなってしまうという事態に陥ってしまい、まるでイベントの体をなさないまま時間が過ぎてしまい、あえなく中止となってしまいました。 当イベントを楽しみにしていた皆様、そして梅田さんはじめJTPAスタッフの方々には、本当に申し訳なかったと思います。ここに改めてお詫び申し上げます。 Macworld 2007のときには180人を収容して何の問題もなく快適に使えていたので、「1000人はわからないけど、200人ぐらいなら大丈夫だろう」とたかをくくっていたのが間違いでした。 今回はその反省も含めて、内部で検証した技術情報をすべて公開し、どのような問題に直面し、どのように解決にあたっているのかをお伝えすることで、特に技術者の皆さんに役立つフィードバックにしたいと思います。 ■今回のアーキテ
-
Aerial over Comet - Blog by Sadayuki Furuhashi
Aerial（エアリアル） - Ajax/Cometの次を行く リアルタイム双方向RPCのトラックバックより引用： 次世代Webアプリケーション基盤技術 - 個人的まとめ他 これは本当に非常に素晴らしい。 ただ、Flash・サーバ間の通信がHTTPじゃなく、Socket(独自プロトコル over TCP)なのが最大の欠点になってしまうと思う。 似たことが出来るAdobeのBlazeDSの最大の利点はやっぱりHTTPで通信してるところなんだと思うし。 BlazeDSどうでしょう - 無題 @ はてな このエントリの通りFlex3でExternal Interface使ってフレームワークとして整えてあげればHTTP版Aerialが完成なんじゃなかろうか。 もしくはサーバをCometにして、Flash側でそれをうまいことラッピングしてプロトコル意識させないようにするとか。 そこで、「サーバーをC
-
Cometと同時接続数制限 - Blog by Sadayuki Furuhashi
HTTPプロキシを通してCometサーバーに接続する場合や、1つブラウザで複数のタブを開いてCometサーバーに接続する場合、同時接続数制限が問題になる。 Cometでは1つのリクエストに対して応答を遅らせるため、クライアント1台がコネクションを1本占有してしまう（pipeliningが無い場合）。 またRFC 2616に、サーバーに対して2コネクション以上張らないようにするべきと書いてある。 ここで、HTTPプロキシの裏に複数のクライアントがいる場合などは、クライアントが3台いるのに2本しかコネクションが使えなかったりする。そうすると1台はリクエストをサーバーに投げられず、サーバーからメッセージを受け取れない。また、クライアントからサーバーへメッセージ送れなくなってしまう。 サーバーから見ると、クライアントがいなくなったのか、同時接続数制限でリクエストが到達しなくなってしまったのかは区別
-
Aerial（エアリアル） - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi
JavaScript - サーバー間で双方向のRPC通信を行う技術は「Aerial」（エアリアル）という名前になりました*1。アイディアを出していただいた皆様、ありがとうございましたm(_ _)m Aerialは、通信にFlashを使い、JavaScriptとサーバープログラムとの間で双方向のRPC呼び出しを行う技術です。つまり、サーバー側からJavaScriptのメソッドを呼び出したり、逆にJavaScriptからサーバー側のプログラムを呼び出したりします。 サーバーから直接JavaScriptのコードを呼び出したり、逆にJavaScriptからサーバー側のメソッドを呼び出したりできるので、通信の内容を意識する必要がなく、バグの混入を抑えます。RPC成分入り！ ライブラリを開発するときも、HTTPやブラウザ間の実装の違いを意識する必要も無く、ごく普通のTCP接続で通信を行うので、Come
-
Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ
-
-
Cometに代表されるサーバ・プッシュ技術の復権
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします。（編集部） サーバ・プッシュの歴史 Webアプリケーションが広まるにつれて、レスポンスやリアルタイム性を重視することが多くなってきました。Webアプリケーションの形式によっては、ユーザーが主体的に操作してデータを取得するよりも、サーバ側が必要と思われるデータを送り付けることが主体の場合もあります。 例えば、Webブラウザを利用したチャットであれば、通常ページが更新されるのはリロードされたタイミングですが、サーバ・プッシュ型の実装がなされている場合は、新しいメッセージが追加された瞬間に、参加ユーザー全員に伝搬されなければいけません。 Webブラウザを活用したサーバ・プッシュの手法は、古くはNets
-
Tomcat 6で実現！ Ajaxを超える通信技術Comet (1/3) - ＠IT
Tomcat 6で実現！Ajaxを超える通信技術Comet：Tomcatはどこまで“安全”にできるのか？（3）（1/3 ページ） Ajaxを超える？ Tomcat 6で搭載されたCometとは？ 前回はTomcatを“安全”に活用するために、ツールを使った運用の仕方やTomcatの設定について解説しました。 今回はTomcatの安全性から少し離れて、Tomcat 6の新機能の利用方法について解説します。Tomcat 6では、いくつかの大きな拡張がありましたが、今回はJ2SE 1.5で実装されたNew I/O API（java.nioパッケージ）を用いたComet（コメット）通信について解説します。 おさらい 「通常のHTTPでの通信」 通常のHTTPでの通信はクライアントのWebブラウザなどからサーバへリクエストを送信し、サーバはリクエストを解釈してレスポンスを返します。つまり、通信のタイ
-
-
-
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました