2014年10月05日

WebからLayer3 (IP layer) を操作する時代が来るかも

フルスタックエンジニアという言葉をよく耳にします。Webアプリ書くときに、通信レイヤの仕組みも分かってないとレスポンス性の高いサービスは提供できないから、ちゃんとNWレイヤも知っておこうねというもの。OSI参照で言うと、layer5 相当のHTTP/1.1 => SPDY, HTTP2に移行してるけど、その下のLayer4 ( TCP )の特性も知っておかないと逆効果にもなりかねない(この辺の詳細は、去年僕が HTML5 Conference 2013で講演した内容を 「SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013」 と、publickey でレポート記事で紹介いただいています)とか。

こういった背景から、長いこと利用されていなかったSCTPが活用されたり、SCTPは改善の余地があるとしてQUICが出てきたりと、Webがトリガーとなって Layer4 で tcp alternative の流れが出てきています。

そんな中、なんとなーく WebRTC がらみで Chromium のソースコード見てたら「あれ、JSからLayer3いじれるオプションがある!」を発見したので、今日はそれについて。フルスタックエンジニアがカバーしなければならない領域は更に広がりそうです。。。

知ってると得するかも知れない、WebRTCのオプションたち

内容は、先週うちの会社のメンバーが主催する WebRTC Meetup Tokyo #4 で、僕がLTした「知ってると得するかもしれないConstraintsたち」ものです。

googImprovedWifiBwe

このLTで紹介したのは、RTCPeerConnection()でP2Pを開始するときに設定できるあまり知られていないChrome独自オプション。例えば、WebRTC ビデオチャットの reference demo https://apprtc.appspot.com/では、


optional: [{"googImprovedWifiBwe":true}]
が入っています。これは、NW帯域推定アルゴリズムを改善されたものにするオプションのようです(Bweは、多分BandWidth Estimationの略だと思う)。通信品質の向上が期待されるので、知っておくと誰でも得しそう。ただ、現在のChromiumのソースコード見ると、このオプションは8月ぐらいのビルドからなくなっているので、多分このアルゴリズムがデフォルトになったのかな?と。そのうち、stableにも反映されるんでしょうね。

googIPv6 & googDscp

あと、それ以外に気になったオプションがこれ(共に、Chrome独自オプションです)。


mandatory: { "googIPv6": true, "googDscp": true }
前者は、P2P通信でIPv6が使えるようにするものだし、後者は Diffserv のフラグをオンにするものです(具体的には、IPv4であれば IPヘッダのTOSフィールドに、IPv6の場合はClassフィールドにビットがセットされます。IPv6で検証したら0x88のビットが立ちました)。元NW屋さんとしては、興奮モノ。

これらが使えると「誰得!?」な訳ですが、現状だと限定的なのは否めません。例えば googIPv6 については、フレッツでIPv6 オプションを enable にしたどおしだと、ISPを経由すること無くフレッツ網内、shortest pathでWebRTC P2P通信できるとか(IPv6オプションONにしちゃうだけだと直接通信をなんでも通しちゃうので、セキュリティリスクがあるのはご承知おき下さい。一般のコンシューマーサービスでこれを前提とするのは現実的では無いかな)。また、googDscp については、これでTOS/Classフィールドにフラグを立てておくと、ルーターで優先制御してくれるので(もちろん設定必要)、ビデオ通話の品質向上に繋がります。イントラネット内でWebRTCやるときには、知っておくと得するかも(Internet出て行く時は、通常このビットは途中でクリアされるので、活用範囲はイントラになるとは思います)。

とまぁ、ある特殊なケースでは得するかな?という設定なわけですが、エンタープライズ向けのシステム構築とかだと、これは知っておくと得するかも。エンプラ向けにWebRTCが本格的に利用されるようになるにはもうしばらくかかるでしょうが、内部検証とかでは今から試しておくと楽しいかもしれません(IPv6が広く使われるようになるころまでには、多分 googIPv6 のオプション自体がデフォルトになるでしょうけど)

フルスタックエンジニアへのニーズは更に高まるかも

面白いなーと思ったのは、これらのオプションって Layer3 を操作するものなんですよね。得に、googDscp なんて、JSからIPレイヤの優先制御をコントロールするものなので、WebからLayer3をコントロールしていることに他なりません。もちろん、このオプションを有効化するためには、JS側からだけではダメで、ルーター側のコンフィグも必要。でも、そうやって考えると、システム作るときにWeb屋さんとNW屋さんが密に連携しなきゃならなくなる日が、そこまで来ているのかもなぁなどと考えてしまいました。

そんな密な連携が必要になったとき、重宝されるのは双方のテクノロジーを熟知したエンジニアなんでしょうね。。。頑張らないと


人気ブログランキングへ
kotesaki at 20:25|PermalinkComments(2)TrackBack(0)clip!webrtc | html5

2013年05月29日

【Chrome packaged Apps v2 追加情報】WebStoreで公開も

先日のポストで Chrome Packaged Apps v2 の最新情報について、速報紹介しました。その中で、

  1. 現在は、Consumer preview の状態。Chrome29がstable(今年の夏ぐらい)のタイミングで Consumer releaseになる
  2. Mobileについては、Apache Cordovaをフレームワークとして、ハイブリッドアプリとして展開される
について紹介しました。今回の記事では、これらの詳細についてお知らせします。

WebStoreでPackaged Apps v2公開!一足先にテストしちゃおう!!

まず、最初に Consumer previewとConsumer releaseの違いについて。Googlerの方に詳細聞いてみたら、現状でもspecial feature ( Socket API とか。既に Experimental 外れてるのでw ) を使ったアプリは、chrome web store で公開出来るとのこと。てことで、早速野良サイトに置いていたWeb-テレビ連携のDLNA controlアプリをchrome web storeに公開してみました。

58
Socket APIを使っているからといって、特に code review プロセスが走るわけでもなく、簡単にdeploy完了(この辺は、Firefox OSのprivileged appとは違う振る舞い)。 試しに、"ADD TO CHROME" してみると、
05
「ローカルネットやインターネット内の他のコンピュータとデータ交換するアプリですよ」と出るのは、Socket API使ってるからだと思う。で、"Add" すると
30
と、しっかりランチャー登録されます。いやー簡単。

ただし、consumer previewのうちは、chrome web storeのサーチでは出てこないとのことで、あくまで直リンク知ってる人だけが利用できる感じ。consumer release (Chrome29がstableになったタイミング)になると、サーチで出るようになりプロダクトとしてdeployできるようになるそうです。

Cordova への packaged apps プラグイン

正式にGoogleからアナウンスされているわけではないのですが、packaged apps v2のCordovaへのプラグインは、github上でオープンソースとして開発が進んでいるようです。

46
ググってたら見つけた代物なので、100%そーとは言い切れませんが、まーどう見てもこれだと思います。これを使えば、packaged appsがAndroidやiOSでも動かせる!きっと。

このgithubでコード見ると結構面白くて、sokcetまわりのコードを見ると、joinGroup(), setMulticastTimeToLiveといったいかにも multicast 関連のメソッドがインタフェースだけ定義されている(リファレンスにはまだ記述されていない)。「へー」と思って、chromiumのudp socket実装見ると、既にこれらのapiは実装されている様子。このメソッド、個人的には結構欲しかったものなので、今度Chromiumで遊んでみようかな・・・

話が脱線しましたが、このCordova 先日のGoogle I/Oでの講演によると、まだ試すには早いとのこと。「只今無茶苦茶頑張ってるから、7月のCordova conferenceまで今しばらく待ってね♪」といった感じでしたので、もうちょっと待ちましょう。

まとめ

今日のポストでは、Chrome packaged apps v2 の現状について、より詳しく紹介しました。サーチでは出てこないながら、すでに chrome web store でpreview公開できますし、Cordova pluginの実装も進んでいる様子。今年はpackaged apps v2から目が離せません


人気ブログランキングへ
kotesaki at 00:13|PermalinkComments(2)TrackBack(0)clip!

2013年05月16日

[Google I/O 2013 速報] Chrome Packaged Apps v2 凄いことに!!

いよいよ、Google I/O 2013 が始まりました!!今年は、初めてのI/O参加で、サンフランシスコに来ています。

基調講演は、昨年のダイブ w/ Google glassに比べると堅実な印象で、大半をAndroidとChromeに時間を割きつつ、一番派手だったのが、Google Maps w/ WebGL。まぁ、Maps GLの流れからすると、「ついに来たか」って感じなので、あまりサプライズという感じではありませんでした。まぁ、基調講演のレポートは各所から出ると思うので、今回の僕の記事では取り上げません。

Chrome/HTML5について、keynoteではそんなにサプライズな感じではなかったのですが、"The Chrome Packaged Apps State of the Nation" というセッションでかなりのサプライズがあったので、今日はそれの速報記事です。

このセッションの内容は、かなりヤバイ!!まだ、セッション資料や Youtubeは公開されていないですが(よく考えたら、セッション資料はなかったので、Youtubeだけが頼りかも・・・)、以降のレポートに興味を持った方は、必ずチェックされることをオススメします。

端的に言うと、「Chrome Packaged Apps v2のAPI」で書いたアプリケーションは、「全てのデバイス/OSで動作する("Write once, run anywhere")」となり、これからのCross Platformでのアプリ開発の本命となるかもしれません。

"Write once, run anywhere" になりえるかも・・・ということで、html5はかなりの注目を集めているわけですが、現状それになり得ないのは詳しい人であれば周知の通り。端的には、

  1. 機能性の欠如(デバイスを直接操作するような low leve api をセキュリティモデル上サポートするのは難しい)
  2. パフォーマンスペナルティ
の大きく2つが挙げられます。で、前者の機能性の欠如に対する解として、昨年のGoogle I/Oでプランがアナウンスされたのが、「Chrome Packaged Apps v2」。「インストールしないと使えない」という欠点はあるものの、それと引き換えに HTML/CSS/Javascript のコーディングパターンで、Socket APIなどのネイティブ並みの低レベルのAPIを利用可能。これを使えば、Webのフレームで、ネイティブと同等のアプリを開発することが可能です。

ただ、コアの開発者の間で一点危惧されていたのが、Androidアプリとの住み分け。「Chrome Packaged Apps v2」が正式リリースされ、仮に「Chrome Web store」がAndroidのChromeでenableになると、機能的にはAndroidアプリと同様のことが可能となる。となると、Andoidアプリや Google Play などの既存資産とカニバリが発生します。なので「一体どーなるんだろー」というのが飲み会のネタになっていました。

その疑問に対して、今回のI/OでGoogleからの答えが示されました。その答えとは、「Apache Cordova(PhoneGapのオープンソース版)」をベースにモバイル版のChrome Packaged AppsのAPIをモバイルでも提供するというもの。このアプローチであれば、Packaged Appsで開発したアプリをデスクトップPC(Chromeさえインストールされていれば、WindowsでもMacOSでもUbuntuでもOK)やChrome OSのみならず、AndroidやiOSでも動作させることが出来ますし、既存のGoogle PlayやAppStoreといったマーケットプレイスとカニバルこともありません。いわゆる "Write once, runs anywhere"が可能となる訳です(Viewの辺りのカスタマイズは必要でしょうが)。
packappv2

ここまでで挙げたのは「WebがNativepアプリをリプレースするに際しての機能的な解決法」。パフォーマンス向上については触れていません。しかし、基調講演ではJSのパフォーマンス向上として asm.js に関するアナウンスもありました(Google I/Oの基調講演でMozillaのアクティビティが宣伝されるのは、かなり面白いと思います)。(追記:読み返してみたら、なんか誤解を呼びそうな感じ・・・ asm.jsがChromeに乗るとアナウンスされたわけでは無いです。キーノートで「Mozillaで、そういう面白いテクノロジーもあるよ」という紹介があっただけです。ということで、以降の”妄想”につながります。)

あくまで僕個人の妄想ですが、機能性として「Packaged Apps v2」、パフォーマンスとして「asm.js」がbindすれば、Webベースのアプリは Native アプリと同等になりえます。さらに、keynoteでも取り上げられていた Web Components が組み合わさると UI toolkitによる開発効率の向上も見込める。となると、「クロスプラットフォームアプリ開発の本命馬として Packaged Apps v2はかなり有力なのでは?」ということになるわけです。

今回のセッションによると、この「Packaged Apps v2」をconsumerが使えるようになるのは Chrome 29。大体ターゲットとしては、夏ぐらいを予定しているとのこと。Web の可能性を大きく変えようとしている「Packaged Apps v2」要注目です。
人気ブログランキングへ

kotesaki at 16:46|PermalinkComments(8)TrackBack(0)clip!

2013年05月13日

Yep, I've released Experimental Web-TV service!!

kaeru5_h360

I have a great news!! Yep, I've released brand-new experimental Web services, that is "Device Orchestration on Chrome Packaged Apps v2" (sorry, current announce page is in Japanese only...) from our company NTT Communications.

This experimental application provides YouTube playlists viewer services on DLNA TV, which you can control from your PC ( Chrome Packaged Apps ). Once user search YouTube, each videos are automatically played so that user doesn't operate too much. Because typical way of viewing TV doesn't require much operation.

orchestration-use04-e

This application uses Socket API which is implemented in Chrome packaged Apps v2. This API's status is experimental. Because of them, installation process is not so easy. (You can check installation manual here )

The usage pattern of this application is shown below.

  1. After launched, automatilly find dlna devices in local network. Please select preferred device. (We have checked SONY BRAVIA and Bubble UPnP (for Android) only)
  2. Search YouTube video.
  3. Video list is automatically played in selected device.
Please note that this application only supports DLNA devices with DMR(Digital Media Renderer) and it has to support H.264 format. It is really rare to find TV made in Japan which supports above, in my investigation SONY's BRAVIA is only in Japan. Easy way to check for this application is using Bubble UPnP , though free version has a limitation of 30 minutes to use DMR feature continuously.

We are now planning that to keep an activity about Web based device orchestration services. Please look forward to!! Any comments are welcome (my twitter account is @komasshu)


人気ブログランキングへ
kotesaki at 22:24|PermalinkComments(3)TrackBack(0)clip!

Web-テレビ連携の試験アプリ公開!! やったーーー :D

kaeru5_h360

去年から試験実装やデモなど行なっていた、WebからのTV連携(PCで検索した YouTube ビデオをDLNA対応テレビに飛ばして表示する)ですが、勤め先(NTTコミュニケーションズ)から試験サービスとして正式に公開しました!!やったーーー :D

名前は、ベタですが "Device Orchestration on Chrome Packaged Apps v2"。 試験公開するに辺り、機能は一点集中型で行こうかなと。で、同僚のsakkuruさん(最近、HTML5とか勉強会のレポートとか書かれています)と「どんな感じにしよっか」と相談。で、
「TVってダラダラ見れるのがいいとこだよねー」
ってことで、YouTubeで検索した結果がエンドレスでTVに流れ続けるというものにしました ;-)。

orchestration-use04-e

最新の Chrome Packaged Apps v2 で動いていて、その機能を使って、DLNAの各種プロトコルを実装(普通のWebのAPIでは無理)。試験機能の Socket API を使っているため、インストール& Chrome の設定変更がチト面倒ですが、ご容赦ください。。。(インストール方法はこちら

以下の様な感じで動きます。

  1. アプリを立ち上げると、自動で周辺のDLNAデバイスを探し出すので、プルダウンから表示させたいデバイス(テレビなんか)を選択する。(※ SONYのBRAVIAとBubble UPnP(Androidのli>Aプレーヤー)でのみ動作確認しています)
  2. YouTubeの映像を検索する
  3. 検索されたビデオリストが自動で再生される
注意が必要なのは、DLNA 機器が DMR(Digital Media Renderer) に対応しており、さらにMPEG4(H.264)の再生に対応していること。僕が調べた限り、この両方に対応している日本製のテレビはかなりレアで、SONYのBRAVIAぐらい(間違っていたらすみません。。。その際は、コメント下さい)。Androidをお持ちの方であれば、Bubble UPnP (無料版だと、30分以上の連続視聴はできませんが・・・)は動作確認済みですので、お試しください。他のデバイスについても、動作確認がとれ次第、順次アナウンスしていきます。(ハッシュタグ #doopa でtweetします)

Webを用いたデバイス連携サービスについては、この試験アプリを皮切りに色々とアクティブに進めるつもりです。是非お楽しみに!!
フィードバックは、この記事のコメント欄や、#doopa のハッシュタグ付き、もしくは、僕のtwitterアカウント (@komasshuに mention いただると嬉しいです)


人気ブログランキングへ
kotesaki at 22:15|PermalinkComments(122)TrackBack(0)clip!

2013年04月14日

WebRTCをお手軽に。Peer.js試してみた

WebRTCへの最近の僕

今年最初のブログ記事ポスト。いやーもう4月も半ば。桜も散っちゃいました。ほんと、更新頻度の低いブログです・・・今日は、WebRTC関連の話題。

DataChannel(映像、音声以外の任意のデータを送受信できる機能)が実装されたり、Firefox nightlyでも実装が始まったり、Chrome for Android(beta)でも実装が始まったりと、最近ホットなニュースが目白押しのWebRTC(Web Real Time Communication)。僕も、ちょいちょいプロトタイプ実装を試しています。

例えば、3/22のWeb先端味見部の時に、当日講師の吉川さんに取り上げていただいたチャット実装(github)とか(その後、吉川さん、大津谷さんのcontributeのおかげで、ビデオチャット機能実装とかバグ改修とか進められています)

なお、上のコードは、サンプルサイト公開もしています。(http://rtcdc.komasshu.info/)お互いに、room no も含め、同一URLにアクセスしたら、両側で"start"をクリック後、片方から"send Offer"をクリックすると p2p でのビデオ and テキストチャットができます。

とにかく面倒くさい

ただ、このWebRTCですが、とにかく面倒くさい。特にRTCPeerConnection APIの部分が、ほんと酷い。細かい話は、僕の以前のブログを参照頂ければ(すみません、この記事書いた時とAPI実装が変わっているので細かい部分は現在とは違っています。あくまで、大枠だけ見てください)と思いますが、

  • セッション情報をやり取りするために、ブローカーサーバーとの通信(WebSocketなんかを使うことが多い)を実装
  • Peer間で、p2pの通信を行うための API call(offer、answer : 映像フォーマットなどのネゴシエーション、candidate : p2p通信用アドレス・ポートのやりとり)や、それにまつわるイベントハンドリング
  • イベントハンドラに応じた、UI(DOM)の制御
と、そのAPIがかなり難解。SIPとかNAT超えとかやってる人だと、比較的すんなり入れると思いますが、そうでないと「なんだよ、STUNとかOfferって」ってなっちゃいます。更に色んな情報制御のプレーンを同時に扱わなければならないため、専門用語に慣れている人でさえ、かなり苦労すること請け合いです。WebGLほどでは無いですが、HTML5系ではかなり難解なAPIです。

上にあげたサンプルコードのクライアントJSの部分はこちらから確認できますが、すごいシンプルなチャットのコーディングでもこれぐらい必要なっちゃう(普通にWebSocketだけで書いたほうが、遥かに簡単)。とてもじゃありませんが、これをスクラッチで使って、もっと複雑なコードを書こうとは思えません。

簡単 WebRTC フレームワーク。Peer.js

てな不満は色んな人達が感じているようで、WebRTC用のフレームワークライブラリがすでに複数公開されています。で、今回は、その中の一つ http://peerjs.com/ を調べてみたので、今回はその内容を紹介します。ちなみに、昨日 NTT-AT の金城さん主催で開催された ふらっと勉強会 WebRTC自習会の際に、色々と調べたものです。

とりあえず、ページのスニペット(UDPサーバー・クライアントのコード)を見ると分かるのですが、とにかくシンプルにWebRTCを使うことができます。多分、WebSocketやsocket.ioのプログラミングに慣れている人であれば、殆ど類似の考え方で使えますので、そんなに苦労しないと思います。

また、WebRTCには別にWebSocketなどによるブローカーサーバーを作らなければならないのですが、これも公開されていて、API keyの申請は必要(僕は試していませんが・・・)ですが、特にブローカーサーバーを作らなくても、簡単にWebRTCを試すことができます。また、ブローカーサーバー自体もOpen Sourceで公開されており、簡単に自分で立てることも可能です(僕は、今回そのアプローチを使いました)。ただし、こちらのAPIはDataChannelのみのフレームワーク(多分)ですので、その点には注意してください。

こちらの、Peer.js。APIが簡単なのもさることながら、内部的に結構充実した機能が実装されており、

各種データタイプへの対応
WebRTCのDataChannelでは、データ送受信フォーマットがバイナリーのみとなっているため、データ送受信時に各種変換処理が必要なのですが、その辺りが簡単に対応出来ます(connect()メソッドの第二引数でデータタイプを指定する。例えば、UTF8でのデータ送受信時には
{serialization: binary-utf8}
を指定する。
reliable通信への対応
WebRTCのDataChannelはUDP通信のため、パケットロスが起きると、データが欠落してしまいます。WebRTCでは、これを防ぐため reliable (再送制御)通信をサポートする仕様策定を進めていますが、現状まだ実装されていません。ここで、実験的ですが、connect()の第二引数で
{reliable: true}
を指定すると、ライブラリにより再送制御が行われるようになります。ただし、現状のDataChannel実装ではデータ送信にトラフィック制限がかかっており、ファイルなどのデータを送信するのに異常に時間がかかったりしますので、あくまで、ショートデータのみに使ったほうが得策です。あと、コードを見ると、reliable:trueを設定した際、serializationの設定がスルーされてしまう実装となっているため、例えばUTF8を送受信するとおかしなことになります。
ブローカーサーバーとのWebSocket / XHR フォールバック
ブローカーサーバーとの通信は、通常はWebSocketが使われますが、失敗するとXHRにフォールバックします。コードを見ると、socket.ioは用いておらず、独自実装のようです。
といった機能がサポートされています(更に詳細は API reference なんかを確認してください(英語))。また、興味のある人は、是非ソースコードもチェックしてみてください。

チャットサンプル

ということで、Peer.jsを使ったチャットサンプルを作ってみました(UTF-8対応版)(reliableはdefaultでfalseになっているので、ロスがあるとデータが途中で落ちちゃいますが・・・)。

まずは、ブローカーサーバー。今回は、自前で立ててみました。nodeのインストールと

$ npm peer
が必要です。無茶苦茶簡単ですw
var PeerServer = require('peer').PeerServer;
var server = new PeerServer({ port: 9000 });

次に、クライアントのコード JavaScritpのみ示します。今回は、ブローカーを独自に立てたため、Peerオブジェクトのコンストラクト時に、オプションでサーバーのアドレスとポートを指定しています。また、UTF-8をサポートするために、connect()メソッドでやはりオプション指定しています。

チャット実装時にUDPサーバーとクライアントのコードを同居しなければならないため、WebSocketのみでコーディングするよりも若干コード量が増えていますが、かなり簡単にWebRTCを利用できることがわかると思います。(生で書くのに比べると段違いの差です

var peer_, conn_;
 
var enableForm_ = function(id) {
	$("form").each(function(e){
		$(this).find("button").attr("disabled", $(this).attr("id") === id ? false : "disabled");
	})
}
var setupForRemote_ = function(conn) {
	if(!!conn) conn_ = conn;
 
	enableForm_("chat");
 
	conn_.on("data", function(data){
		showChat_(conn_.peer, data)
	});
}
 
var showChat_ = function(id, mesg) {
	$("<dt>"+id+"</dt><dd>"+mesg+"</dd>").appendTo("dl")
}
 
$("form#connect").submit(function(e){
	e.preventDefault();
	$(this).find("button").attr("disabeld", "disabled")
 
	var id = $(this).find("input[name=myid]").val();
	peer_ = Peer(id, { 
		"host": "localhost", 
		"port": 9000
	});
 
	peer_.on('connection', setupForRemote_);
	enableForm_("call")
})
 
$("form#call").submit(function(e){
	e.preventDefault();
	var id = $(this).find("input[name=remoteid]").val();
	conn_ = peer_.connect(id, {"serialization": "binary-utf8"});
 
	conn_.on('open', setupForRemote_);
})
 
$("form#chat").submit(function(e){
	e.preventDefault();
 
	var mesg = $(this).find("input").val();
	showChat_("me", mesg)
	conn_.send(mesg)
})
 
function init(){
	enableForm_("connect")
}
init();

HTMLも含めた全体は、gistで確認してください。

まとめ

今回は、WebRTCのDataChannelを簡単に使えるようにするフレームワーク Peer.js を紹介しました。ネットワークゲームとか連携系のサービスなどで、レスポンス性をあげ、かつサーバー負荷を下げることが期待されるWebRTCのDataChannelですが、このライブラリを使うことで、そのコーディング障壁をかなり下げることができます。興味の有る方は、是非お試しを


人気ブログランキングへ
kotesaki at 21:15|PermalinkComments(15)TrackBack(0)clip!

2012年12月23日

Chromeから綺麗に消えた Web Intents。その理由を追ってみる

2012年も残すところあと1週間あまり、明日はクリスマスです。今年1年はWebとデバイスとの連携を中心に色んな活動をしてきました。「最新のWeb技術(Chrome の Socket API)を用いるとブラウザから直接TVを操作できる」ことを紹介し、それと Web Intents を組み合わせると「YouTubeで検索したビデオを、テレビで視聴することができるよ」といったデモ(内容は、下のYouTubeをチェックしてみてください)を紹介してきました。

しかし、残念ながら(たぶん)2012年12月18日以降のChrome canaryで、Web Intents が使えなくなりました(Chromiumの対応Issueはこれ)。10月末ぐらいから、chorme://flags で「有効」にしないとWebページからは使えなくなっていた(Chrome の Web Apps では使えていました)のですが、この度、完全に。。。(まぁ、怪しい状況にあったのは、11月のW3Cの会議で聞いてはいたのですが)チーーーーン

ということで、(おそらく)今年最後のエントリーでは、この辺の事情について書きたいと思います。なお、本エントリーはHTML5 Advent Calendar 2012 の記事です。

デバイス連携に Web Intents は必須ではない

まず、最初に断っておきますが、ブラウザから TV を操作するような、Webベースのデバイス連携を行うに辺り、Web Intentsは必須のAPIではありません(決して強がりではないですよ!!)。TV を DLNA なり、デバイス独自のインタフェースで操作するのに必要となるのは、Socket API(Chrome Packaged Apps v2 のAPI)です。先に紹介したデモで Web Intents がやっているのは、検索した YouTube 動画のURLを渡すところ。デバイス連携シナリオでは、「Webサイトと(デバイスを操作する)Web Appsを簡単に連携する」のが Web Intetns の役目です。

決して Web Intents が今回Chromeから消えたからといって、
Web からのデバイス操作が「オワコン」になったわけでは無い
ですので、その点は注意してください。(でも、あると便利なんだよなーーー。。。。残念)

Web Intentsに対する逆風は UI Issue

「Web Intentsを、現行仕様のまま検討を進めるのは厳しい」ことが正式に表明されたのは、今年の11月にフランス・リヨンで行われたW3Cの技術総会(TPAC2012)。Google の Greg さんよりアナウンスされました(この時の模様は議事録として公開されています)。議事録自体はかなりの長文ですので全てを紹介することは避けますが、Gregさんの冒頭で述べられた発言

... current state, it's behind a flag in Chrome 24
... you go to chrome://flags and enable
... web intents from there
... implementation, mostly UI issues
からかいま見れるように、Web の User Interface と Web Intents との親和性。そして、User Experienceとの親和性が主なポイントとなっています。議事録からそれをまとめると、
Tabブラウザの問題
Web Intentsでは、Web アプリを呼び出すと別のタブで表示される。ここで、Web アプリ間のデータ連携が正常に行われるためには、両方のタブが立ち上がっている必要があるが、タブは簡単に閉じることができるため、APIとして上手く動作しなくなってしまう。
Pickerの問題
普通にWebブラウジングしている最中に、Web Intents でアプリ選択ウィンドウ(ピッカー)が表示されるのは、今までのWebサービスでは無かったこと。Extension や Web Apps に慣れているユーザーであれば、まだ「あーそーゆーことね」となるが、大部分のユーザーにとっては「何これ???」になってしまう。
Persistant connectionの問題
最初にあげたTabの回避策として、アプリをコールした時に新たにタブを開かず、同一ウィンドウの中で遷移する(navigation model)ものがある。しかし、現在の Web Intentsのスペックでは、二つのアプリ間で継続してデータ連携するモデルが入っており、navigation modelとはマッチしない(navigation modelだと、呼び出し元のページは一旦閉じられてしまう)
といった感じです。

上の発言にあるように、この会議の直前に、Chrome://flagsで有効化しないと Web ページからは使えなくし、Web Appsからは、フラグを有効化しなくても使える状態となっていたのですが、これは主に 2 番目の問題に対応するためだったわけです。

他にも類似の API が・・・

Web Intents に関しては、UI/UX以外にも課題があります。それは、類似のAPIがいくつか提案されているという点です。

Web Activity
Mozillaが提案している Web Intents に類似の API。Android IntentsのFirefox OS版という位置づけ。Web Intentsが一般のWebページでも使える一方、Web Activityは Web Appsでしか使えない(なので、前述のタブのような問題もない)
Register Protocol Handler
例えば、mailto: に対してGMailを呼び出すように、特定のプロトコル(mailto:など)に対応するWebアプリを登録する API。Web Intents の中で、片方向の Activity (SHARE、VIEWなど)については、このAPIと機能的にかぶる。
Network Service Discovery API
Operaが提案している、UPnPやmDNS の discovery を実行する API。元々のメインターゲットは、DLNAなどのホームネットワークデバイスをブラウザから操作することを主目的としていたが、自分およびリモートデバイス内のWebサービスを発見し、それと連携する仕組みとして考えると、Web Intents とは機能的にかぶる部分が大きい
このような類似のAPIをマージしつつ、どのように調和をとっていくかは重要な課題。この点も先の議事録の中では議論されています(継続検討のステート)。類似の API がいくつもあるのは、Developer にとって決して良い状況とは言えませんので、きちんと整理・検討していこうとする流れは非常に良いことだと思います。

まとめ

正直 Web Pages 向けにはきついけど、Web Apps 向けには、このまま存続するんじゃないかなーーーと個人的には楽観していた Web Intents ですが、綺麗サッパリ Chrome から消えてなくなってしまいました。ただ、 今回の措置を僕は悲観的には見ていなくて、「Web アプリ間の連携機能を、今一度しっかりと整理しよう。そのために、スタートポイントに戻ろう」という Google からのメッセージなんじゃないかな?と見ています(正式なアナウンスはまだ出ていませんが・・・)。

あと、興味深いのは、こうなった経緯ですね。技術的な API 仕様の問題というより、「現在のWebになじむか」「一般的なWebの利用者が、このAPIを受け入れられるか」というコンテキストから今回の措置は起こったわけで、そういったユーザー目線というポイントが標準化の舞台で大きなインパクトを持つということを、教えてくれます。

研究者・開発者というのは、もちろん「こーすれば便利になるし、みんなハッピーになるじゃん」という気持ちで新しいテクノロジーを生み出そうとするわけですが、それが本当に幸せをもたらすかどうかは、利用者がそれを受け入れてくれるかということにかかっているわけです。それは大切なことと認識しつつ、その観点を見逃してしまいがちになるのが現実だったりするわけですが、標準化という大きな流れの中で、そのことを教えてくれた出来事でした。

Web アプリ連携は大きなテーマ。さて、Web Intentsはどのような形で再構築されるんでしょうか(きっと、完全 give up では無いと、僕は信じています)。楽しみですね!!


人気ブログランキングへ
kotesaki at 20:44|PermalinkComments(14)TrackBack(0)clip!

2012年09月29日

chrome上で、Webサーバーを動かしてみた

Chrome Apps v2's socket api

Chrome の Web appsが manifest v2 に変わり、その機能、特に Packaged Apps が大幅に変わっています。

その中で僕が特に注目しているのが、socket api。ChromeのPackaged Appsから、生のソケットコーディングが出来るようになります。

この socket api ですが、これまで tcp ソケットでサーバーを立てることができなかった(listenとかacceptのメソッドが無かった)のですが、昨日 Google API Expert MTGで 吉川さんから、「昨晩Chromiumで実装されたみたい」との情報が。ということで、早速簡単なWebサーバーを動かしてみました・・・というのが今日のEntryです。(執筆時点では、すでに、canary buildでも動いています)

ということで、早速コードを紹介します。(Chromeの最新canary build 24.0.1280.0 で確認しています。なお、chrome://flagsで、「試験運用版の拡張機能 API 」を有効にするのをお忘れなく)

サンプルコード

manifest.json

{
  "manifest_version": 2,
  "name": "simple HTTP server",
  "description": "something what ridiculous simple web server",
  "version": "0.1",
  "minimum_chrome_version": "24",
  "app": {
    "background": {
      "scripts": ["httpserver.js"]
    }
  },
  "permissions": [
    "experimental",
    {"socket": [
      "tcp-listen"
    ]}
  ]
}

permissionsで、tcp-listenを指定するのがミソです。

httpserver.js

function t2ab(str /* String */) {
    var buffer = new ArrayBuffer(str.length);
    var view = new DataView(buffer);
    for(var i = 0, l = str.length; i < l; i++) {
      view.setInt8(i, str.charAt(i).charCodeAt());
    }
    return buffer;
}

function ab2t(buffer /* ArrayBuffer */) {
  var arr = new Int8Array(buffer);
  var str = "";
  for(var i = 0, l = arr.length; i < l; i++) {
    str += String.fromCharCode.call(this, arr[i]);
  }
  return str;
}


var RESPHEAD = [
  "HTTP/1.1 200 OK",
  "Server: chrome24",
  "Content-Length: {%len%}",
  "Connection: Close",
  "Content-Type: text/html"
]

RESPHEAD = RESPHEAD.join("\r\n")+"\r\n\r\n";

var RESP = [
  "<!doctype html>",
  "<html>",
  "<head>",
  "</head>",
  "<body>",
  "<h1>Welcome!!</h1>",
  "<p>this web server is built w/ chrome's packaged apps v2 feature</p>",
  "</body>",
  "</html>"
]
RESP = RESP.join("\r\n");

var response = function(str){
  var len = str.length;
  return RESPHEAD.replace("{%len%}", len)+str;
}


var rtw = function(sid) {
  // [TODO]
  // call recursive for keep-alive features
  // currently, I haven't tested.
  chrome.socket.read(sid, 65535, function(e){
    console.log(ab2t(e.data));
    if(e.resultCode < 0) {
      chrome.socket.destroy(sid);
      return;
    }
    chrome.socket.write(sid, t2ab(response(RESP)), function(e){
      // [TODO] check datasize
      console.dir(e);
      rtw(sid);
    });
  });
}

chrome.socket.create('tcp', {}, function(e){
  var s = e;

  chrome.socket.listen(s.socketId, "0.0.0.0", 0, 10, function(e){
    chrome.socket.getInfo(s.socketId, function(e){
      console.log("Local web server's URL => http://localhost:"+e.localPort+"/"); // you can check listen port :)
    });
    var accept_ = function(sid){
      chrome.socket.accept(sid, function(e){
        rtw(e.socketId);
        accept_(s.socketId);
      });
    }
    accept_(s.socketId);
  });
});

tcpをacceptしたあと、再度acceptを呼ばないと、2回目以降のtcp接続がハンドルできないため(この動作正しいのかなぁ・・・)、とりあえず簡単なやり方ということで、再帰で書いています(この書き方だと、メモリがちと心配)

動作確認

上記コードは githubに置いておきました。chrome://extensions でこれをインストールすると(「デベロッパーモード」にチェックを入れ、「パッケージ化されていない拡張機能を読み込む」で、該当のフォルダーを指定)、バックグラウンドプロセスとしてWebサーバーが起動します。

ここで、simple HTTP serverの「ビューを調査: _generated_background_page.html」をクリックすると dev tools が起動します。ここで、コンソールのタブをクリックすると、WebサーバーのURLが表示されています。
0929-0

そのURLにブラウザでアクセスすると、以下の画面が表示されます。(Webサーバーで動いているため、ブラウザであればなんでも、アクセス可能です。以下のスクリーンショットは FireFoxとSafariからアクセスした場合)
0929-1

どんなリクエストに対しても、同一リソースしか返さない超シンプルなWebサーバーが起動しましたw

まとめ

今回のポストでは、Chrome apps v2の目玉機能の一つ socket api について、

  • 昨日ついに実装された tcpサーバーのAPI
  • サンプルとしてWebサーバーのコード
を紹介しました。ブラウザでtcpサーバーが起動できると、Web アプリケーションの幅は大きく広がります。これからのWebがますます楽しくなってきましたw


人気ブログランキングへ
kotesaki at 02:52|PermalinkComments(18)clip!

2012年06月16日

WebのNative化に対する標準化が始まる?

昨日、一昨日と幕張で開催されたW3CのWorkshopに参加しました。内容は、Web技術をデジタルサイネージにも適用していこうというもので、僕のほうからは「WebIntentsなどのAPIを利用して、サイネージとスマフォとかを連携すると面白いんじゃない?」といった提案をさせてもらいました(毎度のことながら、自分の英語力の無さに反省しきりなわけですが・・・)。

で、このWorkshopの際、W3C の Michael Smithさんに興味深い動きを教えていただいたので、今日はその紹介をします。

System Applications Working Group

最近、System Applications という Working Group が立ち上がったそうで、そのcharterページ後半に取り扱おうとしているAPIが書いてあるのですが、これが凄い!!
32
一部ピックアップすると

Power Management API
電源周りを管理する。screeのオンオフとか、CPUをスリープモードにするとか
Raw Sockets API
TCPとかUDPなどの生のSocketコーディングを可能にする
Browser API
ブラウザを作るのに必要な機能を提供するAPI
てな感じ。他にも「えぇっ!!」というAPIだらけですので、興味のある方は、是非このページをチェックしてみてください。

WebのNative化に対する標準化という感じかな?

とは言え、これらのAPIは通常のブラウザで動かすことを想定したものでは無いようです。言葉が適切か微妙ですが「WebのNative化に対する標準化」と言えるんじゃないかな?という気がします。

WG Charterの Goal として以下を述べています。

The System Applications Working Group aims to produce a runtime environment and a set of APIs that let applications integrate closely with the operating system's functionality using nothing but the Web platform. Creating the ability to produce applications relying solely on the web platform extends the reach of the Web to new places and opens the door to greater cooperation between the Web and the operating system.

〜System Application WGではWebプラットフォームのみを用いOSの機能を利用したアプリケーション開発を行えるランタイム環境とAPI群を提供することを目的としています。Webプラットフォームによるアプリケーション開発に対し、WebとOSとの連携に対する扉を開くことで、Webは新たな領域へと踏み出していきます。〜 (上手く直訳できなかったので、少し意訳を入れています)

つまり、OSのネイティブ機能を使ったアプリ開発をWebプラットフォームで可能にしようと。

さらにそれ以降の節を見ると、WGの目的がよりクリアとなっていきます。

  • 「通常のブラウザから使うことを目的としていない」
  • 「Boot2GeckoやTizenを議論を始めるにあたっての参照点としている」
  • 「メインの言語はJavascriptをターゲットとしているが、他の言語利用も考慮に入れる」
などなど。

ここからは、あくまで僕の私見なのですが、現在「Boot2Gecko」「Tizen」「ChromeOS (NaCl)」「Windows8(MetroUI)」といったWebとOSとの融合を図る製品が次々と発表されています。これらは、いわゆる「HTML + CSS + Javascript」でネイティブアプリ開発を可能にしようというもの(だと僕は理解しています)で、通常のブラウザからでは利用できないOS機能にもアクセス可能です。
これは大変素晴らしいことなのですが、一点懸念されるのは「OS固有機能へのAPIがベンダー独自になってしまわないか?」という点。こうなると、そこでfragmentationが起きてしまい、Webの利点・基本思想がどんどん失われていってしまいます。

このような動きに対して、このWGはそれらの機能に対しても標準化をすすめることで、ベンダーごとのfragmentationを避けようとしているんじゃないかな・・・と。それにより、Webのさらなる進化を加速していこうとしているんじゃないかなと僕には写りました。あと、多分こういった動きって、PhoneGapのような開発フレームワークにも反映されていくんじゃないかなと勝手に想像しています。

ネイティブ開発に対しても、Webのマルチプラットフォーム性が適用されていく。それってホントに素晴らしいことですよね。こうなってくると
「WebアプリとNativeアプリどっちがいいのか?」
という議論もいずれはなくなってしまうのかもしれません。(と、自分で書いててなんですが、そこは微妙かも)

まとめ

今日は、W3Cで新たに作られた System Applications Working Groupについて紹介しました。様々なOS固有機能を用いたアプリケーション開発をターゲットにしたもので、NativeアプリをWeb技術を使って開発する際の標準化と位置づけられます。
Webの進化は、ホント止まりませんね!!いったい、どこまでいくのやら :)


人気ブログランキングへ
kotesaki at 12:48|PermalinkComments(22)TrackBack(0)clip!html5 | WebIntents

SPDY on nginx!!

今日spdy-devのMLに「nginxでspdy対応したよ!!」がPOSTされたので、早速 share

1.3.xへのパッチとして提供されています。インストール方法などは以下のURLをチェックしてみてください。

http://nginx.org/patches/spdy/README.txt

僕まだ試せていませんが、nginxが対応するとテンション上がりますよねw いやホントSPDY熱いっす。


P.S. 来週 App Engine ja nightでSPDYについて講演します。


人気ブログランキングへ
kotesaki at 00:50|PermalinkComments(19)TrackBack(0)clip!SPDY