Google、アプリ内購入機能をChromeのCanaryビルドに実装―やがてデスクトップにもフリーミアム時代が来る

Chromeはそれ自体がプラットフォームだ。そこでGoogleは機能のさらなる拡大に全力を挙げている。デベロッパーでChromiumエバンジェリストのFrançois Beaufortの TheNextWebへの投稿 によれば、次のステップはブラウザおよびChrome OSにアプリ内支払機能を組み込むことだという。つまりウェブ・アプリのデベロッパーはChromeをほとんどAndroidのようなモバイル・プラットフォームのように扱えるようになる。

現在この機能を利用するためにはいくつか制限がある。まずChrome Canary Buildのみに提供されているが、これは安定版から一番遠い実験版だ。またChrome Packaged AppsでGoogle Wallet App for Chromeをエンベッドしなければならない。おそらくこの機能が近々安定版で公開されることはなさそうだ。しかしやがてウェブ版ChromeアプリとChromebookコンピュータにこの機能が組み込まれることになる可能性は高い。

これはデベロッパーにとっては、モバイル・アプリで大いに成功している無料で試せるフリーミアム形式のアプリを開発することが非常に簡単になることを意味する。フリーミアム・アプリはAndroidのアプリの売上総額中で圧倒的なシェアを占めている。このことは最近のI/OカンファレンスでGoogleが疑問の余地なく強調していた

このニュースに符合するように、Mozillaはウェブ上での支払いの標準APIを開発中だ。これは先ごろ発表されたGoogle Walletのデジタル・コンテンツ購入のためのAPIに触発されて開発を決めたものだという。Mozilla側ではアプリ内支払機能については特に言及していない。Mozillaはオープンなウェブを目指しており、Google WalletのAPIのようにクローズドなChromeアプリ環境を対象にしていないからなのだろう。 しかし、将来はMozillaのAPIもアプリ内支払いに拡張されるかもしれいない。

ユーザーのモバイル化が進む中、アプリ内販売はデジタル・コンテンツのプロバイダーにとって最良の選択肢になりつつある。Androidの成功のおかげで大いにユーザーを増やしつつあるGoogle WalletとChromeを組み合わせることによってデスクトップでもその選択肢を拡大しようというのは非常に賢明な作戦だ。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Chrome Beta 28に新たな通知機能(デベロッパがカスタマイズ可)を導入–ブラウザが閉じていても有効

これは実は、待望のデスクトップ版Google Nowとは言えないが、Googleは今日(米国時間5/23)、Chromeに充実した通知能力をもたらすための機能をChromeの最新のベータバージョン(v28)に導入する、と発表した。これで、Google Nowがまた一歩デスクトップに接近してきたことは、確実である。

この新しい通知機能は、デベロッパが自作のChrome用パッケージアプリやエクステンションに容易に加えることができ、通知はブラウザのウィンドウの外にポップアップするので、ユーザはブラウザを開いてなくても通知を受け取れる。

この機能が今使えるのはWindowsとChrome OSだが、OS XとLinuxも“もうすぐ”対応だそうだ。

Chromeにはもちろん前からWeb上のベーシックな通知機能があり、ChromeとGoogle AppsのユーザはGmailなどで通知を体験してきたはずだ。しかし今回発表されたリッチな通知は、一味も二味も違う。デベロッパが独自のアイコンや画像やヘッドライン(見出し)や短いメッセージを、通知に添付できるのだ。また通知の表示持続時間や複数の通知アラートのプライオリティをデベロッパは指定できる。

WindowsのシステムトレイやChrome OSのランチャから、新たにできた通知センターにアクセスできる。

先週Googleは、Chromeにプッシュ通知サービスを実現するクラウドメッセージングを発表した(本来はモバイルAndroidの機能)。今日の発表にそのことの言及はないが、通知センターにはこのプッシュ通知も当然入るはずだ。

Chrome 28に盛り込まれた新機能や変更の詳細は、ここで見られる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Android版Chrome、全画面モードを追加、オムニボックスからの検索を簡易化。iOS版にも音声検索追加へ

Chrome 27のデスクトップ版が昨日公開され、今日(米国時間5/22)Googleは、Andorid版Chromeもバージョン27にアップデートした。デスクトップ版のアップデートは主として性能改善だったが、Android版には新機能がいくつか追加された。一番大きいのは、スマートフォンの全画面モードだろう。iPhoneアプリ(あるいはかつてのAndroidブラウザー)と同じように、スクロールダウンするとツールバーが消える。

さらにこのバージョンでは検索体験がいくらか簡易化された。オムニボックスから検索した際「検索クエリがオムニボックスに表示されたままになるので、編集が容易になり、検索結果の表示が増える」とGoogleは言っている(下図参照)。

Googleでは類似の機能をデスクトップ版Chromeでも実験している。これは、オムニボックスを事実上Google.comの検索フォームに変えるものだ。これまでは、表示を検索結果のURLに切り替えてから、検索結果ページ上に検索インターフェースを再現していた。デスクトップでは、新しいやり方はいつも私を混乱させるのだが、画面サイズの制約を考えれば、これでスクロールせずに検索結果を何行か余計に表示できるのだろう。

他にこのアップデートで加わった新機能には、クライアント側認証(企業のイントラネットに接続する際によく必要になる)とタブレット版でのタブ履歴(戻るボタンの長押しでタブ履歴を見ることができる)がある。

iOSはどうなるのか?

iPhoneおよびiPad版Chromeにも近々音声検索が追加されると今日Googleが発表した。公開は数日以内の予定で、ユーザーは「ローマの天気は?」「サンアントニオからダラスまでは何マイル?」などの質問ができるようになるだろう。

[原文へ]

(翻訳:Nob Takahashi)


Google、Chromebookを公衆インターネットキオスクにする新モードを提供

Googleは、Chromebooksは「シェアするため」にあると常に言ってきたが、ゲストモードはあるものの、このデバイスが公衆インターネットキオスクに向いているとは必ずしも言えなかった。今日、Googleは “Managed Public Sessions” 機能を公開して状況を変えようとしている。Googleによると、新機能はChrome OSデバイスを「ログインすることなく高度なカスタマイズが可能な体験を顧客にも従業員にも提供する」インターネットキオスクに変える。

この新モードによって、ChromebookとChromeboxは、顧客が品切れ商品を買えるようにしたい商店や、従業員が製造フロアから在庫を更新できるようにしたい工場、ビジネスセンターに新たな機能を追加したいホテル等にとって、これまで以上に有用な選択肢になると、Chromebookチームは信じている。

デフォルト設定では、バブリックセッションのデータはログアウト後にすべて消去される。

GoogleによるとAdminは、これらのデバイスを通常のウェブベースのChrome OS管理コンソールから操作できる。つい最近Googleは、この管理コンソールをアップデートし、Adminが各Chrome OS端末のホームページやブロック設定等の詳細を管理できるようにした。

Googleはこのモードを、Dillards、 オレゴン州のマルトノマ群図書館、Hyatt Regency San Franciscoなどの組織でテストを続けてきた。

[原文へ]

(翻訳:Nob Takahashi)


Microsoft Officeの文書をブラウザ内で開けるプラグインがChrome Beta用に登場

Microsoft Officeの文書をブラウザで見なければならない機会が多い人たちのためにGoogleが今日(米国時間4/25)から、そのためのChromeエクステンションを提供する。具体的には、WordとExcelとPowerPointのファイルだ(.doc, .docx, .xls, .xlsx, .ppt, .pptx)。これまではGoogle Driveのビューワで見ていたが、エクステンションChrome Office Viewer(まだベータ)をインストールするとブラウザ自身がこれらの文書を開けるようになる。

OSがChrome OSであるコンピュータChromebookには前からこの機能があったが、今ではWindowsとMacのChromeブラウザでも利用できる。ただし、安定版ではなくChrome Betaを使うこと。

この20メガバイトもあるプラグインは、専用のサンドボックス内でファイルを開くからマルウェアにやられない、とGoogleは言っている。“だから汚染されたOfficeファイルを使っても、それが個人情報を盗んだりユーザのアクティビティを監視することはできない”、という。

Googleは今日の発表の中で何も言っていないが、昨年買収したQuickofficeの技術が、このプラグインにかなり貢献しているのだろう。Googleが2月にPixelという名のChromebookをローンチしたときは、同社のNative Client技術を使ってQuickofficeをChromeに移植する、と言っていた。それからすでに3か月が経とうとしているから、Office文書をブラウザ内でどうするかという発表が、Googleからあってもおかしくないタイミングだった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


古いWebアプリを自動的に古いブラウザで開ける–Chromeの企業ユーザ向け設定

Googleが今日(米国時間4/16)加えた新しい機能により、Google Apps for Businessのユーザは、Chromeブラウザを企業にとってもっと使いやすくできる。Google Apps for Businessと〜〜for EducationのためにGoogleがクラウドから提供している管理ツールによりITのアドミニストレータは、標準のGoogle AdminパネルやWindows Group Policiesから、100項目以上のChromeのポリシー(方針項目)やプリファレンス(選好項目)をカスタマイズできる。

さらに、Googleが今日新たにローンチしたChromeのエクステンションにより企業は、昔のブラウザを必要とするサイトを見るために自動的にレガシーブラウザに切り替えることができる。それらのサイトは、ITの管理者が定義する。Chrome Frameを使うとChromeのレンダリングエンジンを古いブラウザで使えるが、Googleの今日の注記では、“Legacy Browser Supportがあることにより企業のITアドミンは〔安心して〕現代的なWebへの完全移行ができる”、という。

Chrome for Businessのクラウド上の管理システムは、 Google Apps for Businessと〜〜for Educationの全ユーザが利用できる。そのポリシーの設定は、Windows、Mac、そしてLinux上のビジネスアカウントでChromeにサインインするユーザに自動的に適用される。

その企業のChromeユーザに対しては、どこでChromeを使っていても同じポリシーにより、IT部門が決めたWebアプリケーションやエクステンション、スタートアップのURL等のセットアップが行われる。さらにITの管理者は、WebGLコンテンツの視聴や共有の可否、セーフブラウジングモードの設定、シークレットモードの設定、画像を見ることの可否など、より詳細なセットアップもできるし、またURLのブラックリストによる管理もできる。

Googleは今日の発表声明の中で、“Webとブラウザは最近の20年で大きく変わった”、と言っている。“Chromeブラウザは現代のWebで可能なことの範囲を継続的に拡大しつつあるが、そのイノベーションはどこにいる誰にとっても、とりわけ職場において、可利用にならなければならない”。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


BlinkとServoとRust: ブラウザの次の進化の方向性が見えてきた

先週は、ぼくのようにブラウザを追っているブロガーにとっておもしろい週だった。週の終わりには、Internet Explorer 11がWebGLとSPDYをサポートするらしい、という話も聞いた。その前の火曜日にはMozillaがメールで、MozillaのCTO Brendan Eichへの電話インタビューの可能性を打診してきた。その話題は次世代のブラウザエンジンServoと、それが書かれているプログラミング言語Rustだ。しかしMozilla Researchが単独でこれらを手がけているのではなく、この、マルチコアプロセッサと異種混成的なアーキテクチャ向けに最適化されている新型エンジンをAndroidとARMに実装する作業には、Samsungが協力しているのだった。MozillaはこれまでServoについてあまり何も発表しなかったから、今こうやって大きく発表することは少々意外だ。

おもしろいことに、GoogleのChromeのチームが話をしたいと言ってきたのも、先週の火曜日だ。おかしなことに、そのときの広報の連中は、いつもと違って、詳しい話を何もしない(通常は、何の話かぐらいは事前に教えてくれる)。Googleのエンジニアリング担当VP Linus UpsonとOpen Web PlatformのプロダクトマネージャAlex Komoroskeは、WebKitをフォークしてWebKitベースの独自のレンダリングエンジンBlinkをローンチする、と言った。ぼくは自分が話を聞き間違っていないか気になって、何度も彼らに念を押した。WebKit開発の外部の人間ににとっては、GoogleがWebKitの本流を去るという話を、にわかには信じられない。一般的にWebKitは、ChromeとSafariのおかげでデスクトップとモバイルで大成功した、と見られている。それを独自フォークする理由が、思い当たらない。

でもBlinkは正しい

だからGoogleのWebKitフォークは先週のいろんな発表やリークの中で、いちばん話題になった。Googleはフォークの理由を純粋に技術的なものと言うが、WebKitは今でもAppleとGoogleが仲良くやっている数少ないものの一つだから、政治的動機も疑われる。しかもWebKitへのコード貢献量は、このところGoogleが最大なのに。

今後の成り行きを予言するのは早すぎるが、ぼく自身はかなり楽観的だ。たしかに、Webデベロッパが自分のコードを試験すべきレンダリングエンジンが一つ増えてしまう。でもChromeのチームによれば、それは彼らにとって“苦渋の決断”だった。Googleはレンダリングのスピードを上げたいが、WebKitは今いろんなブラウザで使われている。だから、WebKit本流における抜本的な改作は難しい。

Chromeのチームは、“ブラウザが複数あることと同じく、レンダリングエンジンも複数あった方が、今後の健全なイノベーションを刺激し、オープンなWeb全体のエコシステムの健康にとって良い”、と考えている。たしかに、そのとおりだろう。2008年にChromeが突然現れてから、ほかのブラウザのイノベーションは加速した。当時の競争の中心は、高速なJavaScriptエンジンの開発だった(そしてWebKitを使っているブラウザも、JavaScriptエンジンはそれぞれ違っていた)。BlinkとServoという新しい馬が走り出した今は、レンダリングエンジンも重要な競争の要素になり、そしてその競争は、より速くてより安定的なブラウザを求めるユーザとデベロッパに利益をもたらす。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


GoogleがWebKitをフォークして新レンダリングエンジンBlinkをローンチ, 速さと単純性を追求

Googleがさきほど(米国時間4/3)、WebKitのフォークBlink発表した。Googleの説明によると、Blinkは“包括的なオープンソースコミュニティ”および“WebKitをベースとする新たなレンダリングエンジン”であり、将来的には当然、“WebKitとは異なる方向へ進化していく”。Googleによると、Blinkはスピードと単純性がすべてだ。それはもうすぐChromiumからChromeのさまざまなリリースチャネルへ持ち込まれ、ユーザは近い将来、ChromeのBlinkで実装されたバージョンをデスクトップや携帯やタブレットで見ることになる。

WebKit: コラボレーションは最高だったが

Googleの技術担当VP Linus UpsonとOpen Web PlatformのGoogle側プロダクトマネージャAlex Komoroskeの話では、WebKitをフォークする決定は完全に技術者チームからの発意であり、その動機はただ一つ、WebKitの技術的複雑さと、それがもたらす束縛だ。Komoroskeによると、WebKitプロジェクトにおける他社との協働関係そのものは、たいへんすばらしかった、という。

しかし、プロジェクトの立ち上げまでには難関もあった。Upsonによると、このWebKitフォークの動きに関して、“管理部門からは厳しい質問を大量に投げかけられた”が、結局は、技術的な複雑性を軽減して、Googleのレンダリングエンジンをチームが望む方向に進化させていくことが優先された。

Blinkはスピードと単純性がすべて

Komoroskeによると、具体的な問題としては、Chromium(ChromeとChrome OSを支えるオープンソースプロジェクト)の多重処理を核とするアーキテクチャは、WebKitとの相性があまり良くなかった。GoogleがWebKitでGoogle流を貫こうとすると、WebKitのほかのパートナーたちとの統合という課題が発生し、開発過程の全体を牛歩にしてしまった、とKomoroskeは回顧する。

ChromiumとBlinkはオープンソースプロジェクトなので、誰もが自由にコミットできるが、この種のプロジェクトの通例として、そのためにはプロジェクトの正規メンバーである必要がある。

現時点ではWebKitとBlinkは機能的にほとんど同じだが、Googleの予想としては、長期的には両者は非常に違った方向に進化していくだろう。たとえばKomoroskeは、IFRAMEを別のプロセスとして実装したいと考えているが、それを今のWebKitでやるのはきわめて困難だ。

ただし今のところは作業の中心がアーキテクチャのレベルでの改良なので、機能や見た目の上での違いはほとんどない。Googleによると、今行われている改良とはたとえば。“7つのビルドシステムを取り除き、7000あまりのファイル(計450万行あまり)を一度に削除する”、といった低レベルの作業だ。このような大掃除によって、コードベースがより健康的になり、安定性が増し、バグが少なくなる、とGoogleは期待している。

WebKitプロジェクトは、Appleが同社のSafariブラウザのためにKDEのオープンソース製品KHTMLエンジンをフォークするところから始まった。その後KHTMLのチームとAppleのあいだにいろんなやりとりや経緯があり、Appleは2005年にWebKitをオープンソースにすると発表した。そしてGoogleはそれを、同社のChromeブラウザに採用した。興味深いのは、初期のChromiumが実はWebKitのフォークされたバージョンを使っていたこと。そしてその後、そのフォークがあらためて、WebKitプロジェクトの本流に合流したことだ。

というわけで、今現在WebKitを使ってブラウザを作っているベンダは、実はすでにそれぞれが、きわめて異なった実装を使っているのだ(そして彼ら独自のJavaScriptエンジンも使っている)。

WebKitの開発におけるGoogleの今の役割

目下、WebKitのリビュワーの大多数がGoogleから(95名)で、次に多いのがApple(59名)だ。以下、Blackberry、Intel、Nokia、Samsung、Adobe、Netflixなどが続く。WebKitのリポジトリへのコミットも、その大半はGoogleがやっているから、Googleが脱けたら今後のWebKitがどうなるのか、それを見守っていきたい。Googleの広報は今日、Blinkのチームメンバーは今後も“そうしたければ”WebKitに貢献できる、と言ったが、おそらく、そんな余裕のない人がほとんどだろう。

WebKitに切り換えたばかりのOperaはどうなる?

数週間前にOperaは、独自のエンジンの開発をやめてWebKitに切り換える、そのためにブラウザのベースとしてはChromiumを採用する、と発表した。今回のGoogleの発表がOperaにどう影響するのか、それはまだ分からないが、本誌は同社に声明を求めている。

Operaが切り換えを発表したとき、多くのデベロッパたちがWebKitによる文化的独占を心配した(とくにモバイルのWebで)。GoogleがBlinkを手がけたことにより、その心配はなくなり、イノベーションが再び加速すると思われる。Komoroskeも、GoogleのWebKit離れにより他社もWebKitをよりはやく開発するようになり、Googleのこれまでとはまったく異なる実装(Blink)がその動きを一層刺激するだろう、と言っている。

アップデート: Operaが今、次のような声明を寄越した: “Webがデベロッパにとってさらに一層オープンになりアクセスしやすくなることは、喜ばしい。それは動きの激しいプラットホームであり、継続的かつ迅速な更新が必要とされる。Googleのブラウザ担当者たちと話し合った結果、弊社は今後、オープンソースのプロジェクトすなわちBlinkに貢献していくことを志向したい。弊社からのインプットを有効利用できると思われるさまざまなオープンソースのプロジェクトに対して、これまでもそうしてきたように”。

なぜ”Blink”か?

Googleはなぜ、新しいレンダリングエンジンをBlink(まばたき)と呼ぶのか? Upsonによると、それは当然、スピードと単純性を重視するからだ。しかしブラウザのデベロッパたちには、名前で遊ぶ傾向が以前からある。たとえばChromeは、”chrome”(派手で中身のない外見)をできるかぎり消滅させることと関連している。そして彼によるとBlinkは、90年代にNetscape Navigatorが導入した、古き良き(そして迷惑な)<blink>タグを、人びとに思い出させるためだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Chrome for Androidでは(なんと!)Web通信がすべてGoogleのプロキシサーバを経由する

chrome_beta_logo

Googleがさきほど(米国時間3/5)、Chrome for Androidのベータに、モバイルのChromeユーザのWeb閲覧を高速化し帯域を節約するための新機能を実装した、と発表した。それは一種のプロキシサーバ機能で、この機能をonにしておくと、ユーザのWebリクエストとそれに対するレスポンスがすべてGoogleのサーバを経由するようになり、そこでGoogleは同社のPageSpeedライブラリを使ってコンテンツを圧縮し最適化する。そしてその後の、Googleのサーバとブラウザ間の通信はSPDYプロトコルで行われることになり、なお一層の最適化が図られる。

このプロキシは、データ量を約半分に圧縮する。今のWebは伝送量の約60%が画像データだから、画像をJPEGやPNGからPageSpeedライブラリのWebP形式〔日本語〕に変換するだけでも、違いは大きい。GoogleのソフトウェアエンジニアでモバイルWebのパフォーマンス向上を担当しているMatt Welshが今日の発表声明の中で、“HTMLとJavaScriptとCSSのリソースにインテリジェントな圧縮縮小を施すことにより、不要なホワイトスペースやコメント、およびそのほかの、ページのレンダリングには不必要なメタデータが取り除かれる”、と書いている。DNSの参照もプロキシが独自に行い、また、この機能をonにすると、ブラウザは自動的にSafe Browsingモード〔日本語〕になる。

spdy_proxy_google

この機能をonにするには、ブラウザでchrome://flagsへ行き、“Enable Data Compression Proxy”をセレクトする。

この機能がonのときでも、HTTPSによるリクエストは直接、目的サイトへ行き、その通信はGoogleのサーバを経由しない。シークレットウィンドウ/タブに関しても同じだ。

Operaがモバイルとデスクトップの両方で提供しているTurboモードによく似ているが、違いはページのレンダリングをすべてユーザのブラウザが行うことと、JavaScriptの処理もすべてローカルに行われることだ。

Chromeのこの新たなベータバージョンではさらに、パスワードと自動補完のシンクがサポートされる。この機能はこれまで、デスクトップのChromeにしかなかったが、しかし今回の主役は言うまでもなく、プロキシサーバによるSPDYのサポートだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Chromeブラウザ(とGoogle Docs)のスペルチェッカーが賢くなった

chrome_beta_logo

今日(米国時間2/26)リリースされたChromeバージョン26のベータでは、スペルチェッカーが更新された(ブラウザ内とGoogle Docs)。新たに韓国語とタミール語とアルバニア語がサポートされ、また改良箇所も多い。しかし、いちばん重要な新機能は、Chromeの設定を複数のデバイスでシンクするときに、ユーザのカスタム辞書もシンクできるようになったことだ。だからユーザの名前の綴りとか、一部のスタートアップの名前などが、スペルチェッカーのデフォルトから見ておかしくても、それを新しいChromebookなどの上でうるさく指摘されることはない。

spellcheck

またスペルチェッカーの”Ask Google for suggestions“(Googleにサジェッションを求める)機能が改良され、ブラウザの辞書だけでなくGoogleのWebサービスも見てスペルを提案するようになった。Googleはこの新機能について、“英語における、文法/同音同綴異義語/文脈感知型のスペルチェックを提供する。それはGoogle検索で今使われている技術と同じものである”、と言っている。今は英語だけだが、ほかの言語ももうすぐ対応するそうだ。

また、これからはスペルチェッカーが、“ ‘Justin Bieber’、 ‘Skrillex’などの固有名詞を理解するので、たとえばDananananaykroydでnをいくつ書くべきか(正解:4つ)思い出せなくても、もう大丈夫”、だそうだ。

WindowsとLinuxとChrome OSのユーザにはChrome v26の安定バージョンがもうすぐ提供される。Macのサポートは、やや遅れるらしい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Firefoxの先行テスト版がWebRTC, H.264, MP3をデフォルトでサポート

Mozilla_Nightly_icon_2011

Firefoxブラウザのテスト専用の先進的バージョンFirefox Nightlyで、WebRTCがデフォルトでサポートされた。WebRTCは、プラグインなしでブラウザ自身がリアルタイムのUDP通信を行う規格で、とくにオーディオやビデオによる対話やコンテンツ配布に適している。これまではFirefox Nightlyのオプションとしてサポートされていたが、これがデフォルトになったことにより、数か月後には安定版(正規リリース版)の工程に組み入れられることが期待される。

MozillaのPaul RougetとRober Nymanが今日の発表声明の中で、“これは大きな前進である。これにより特殊な設定や構成を必要とせずにWebRTCを直接、Webブラウザの中で動かせるようになる”、と書いている。

おそらく今年いっぱい、WebRTCがにぎやかな話題になるだろう。主なブラウザがこぞって、その実装を開始しているからだ。Chromeはすでにバージョン23から安定版でWebRTCをサポートしており、最近Mozilla とGoogleは、二つのブラウザのユーザ同士がWebRTCを使って対話できる、というデモを公開した。

なお今回のFirefox Nightlyでは、H.264とMP3形式がサポートされる。ただしデコードはオペレーティングシステムが行い、今はWindowsの7以上のみでサポートされる。MacとLinuxのサポートは、目下開発中だ。

Mozillaが今週初めに発表したように、このNightlyリリースはWindows 8のMetroインタフェイスをサポートしている。

WebGLのデモも…

ちょっと関係のない話題だが、Mozillaは今日(米国時間2/20)、WebGLの すばらしいデモ発表したACTISKUのAnthony Liotが書いたこのデモは、Webブラウザもついにここまで来たか!と思わせる最先端のグラフィクスであり、しかもデベロッパはプラグインに依存せずにクロスプラットホームな体験をユーザに容易に提供できる。ただし現状では、Internet ExplorerがまだWebGLをサポートしていない。

webgl_demo_actisku

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

WebKitの独占状態の是非

icon-goldOperaが自前のレンダリングエンジンの開発を停止し、オープンソースのWebKitエンジンを採用することにしたというニュースは各所から大いに注目を集めた。WebKitはGoogleのAndroid向けブラウザでも、またAppleのiOS向けブラウザにも採用されている。すなわちモバイル環境においては、既に事実上の標準の地位を獲得している。そしてさらにその触手をデスクトップ環境にも伸ばしつつあるところだ。既にChromeは、Tridentを採用しているMicrosoftのInternet Explorerや、MozillaのGeckoを採用しているFirefoxと比べてかなりのリードを獲得している。こうした状況の中で、頭に浮かぶ疑問がある。各社が独自のエンジンを開発して、競い合う環境の方が良いのか、それともWebKitを標準として各社に採用してもらう方向が望ましいものなのだろうか。

WebKitはオープンソースのプロジェクトであるので、誰でも開発に参加することができる。Google、Apple、Mozilla、Microsoft、Opera、あるいはブラウザ関連のさまざまな企業が参加しているので、標準的に採用される技術を即座に実装することができる。レンダリングエンジンが統一されることで、開発者の苦労は大いに低減されることとなる。レンダリングエンジンの違いによる細々とした表示スタイルの違いに頭を悩ませないで済むようになるわけだ。

Hacker Newsのスレッドにも多くのコメントが寄せられている。WebKitの開発に集中することで、多くのイノベーションが生み出されるのであれば、WebKit独占の状態は開発者にとっても利用者にとっても良いものとなる可能性があるという論調もみてとれる。

こうした独占に向けた流れに抵抗する筆頭はMozillaだ。これまで独自のGeckoエンジンおよび、その後継となるServoに多大なリソースを割いてきた。Mozilla CTOのBrendan Eich曰く、Mozillaの存在意義をかけて独占には抗っていくつもりだとのこと。また、MozillaエンジニアのSteve Finkは、モバイルかデスクトップかを問わず、WebKit独占を許してしまえばイノベーションが阻害され、少数企業によるプラットフォーム独占を惹起してしまうと述べている。そのような状況になれば、結局は各社利益を追求する迷惑な混乱に支配されてしまうことになるとも述べている。

しかしWebKitはオープンソースであるので、もし開発が滞ったりあるいは特定のステークホルダーが開発を政治的理由によって妨害するようなことがあれば、即時に開発の道筋を分岐させることができるので、独占による悪影響などはないと考える人もいる。

From Google's Chrome Launch Comic Book

但し、ウェブの世界ではこれまでにも「独占の弊害」を経験したことがある。IE5やIE6の時代(Netscapeが舞台を去り、そしてIEは6のリリースが2001年で、IE7が登場したのは2006年だった)には、完全に「停滞」状況になっていた。そうした状況の中、2004年あたりからはFirefoxがスタートし、そしてWebKitをベースとしたGoogleのChromeも2008年に登場してきたのだった。Chromeのミッションはレンダリングエンジンの標準化を試み、そしてJavaScriptの高速化を行うということだった。独占を崩す存在が登場してきたことにより、ウェブプラットフォームは現在のような応用環境に進化したのだとも言えるだろう。

「ウェブ」が今後戦っていく相手は?

Operaは、「独占状態は良くない」と主張しつつ、その言葉とは正反対にも見える道を歩むことになった。Operaもそれなりのシェアを獲得しているにも関わらず、「多くの開発者たちがWebKitのみをターゲットに開発をしているという現状があります」と述べ「先頭に立って独自の道を追求していくことにメリットは少ないと判断しました」とのこと。

Operaの選択した方向は興味深いものだ。結局のところ、ウェブ技術は各社のレンダリングエンジンの違いで競っていくのではないと判断したわけだ。今後の競合相手はネイティブアプリケーションであると判断したわけだ。Operaは「閉鎖的な“アプリケーション”に対抗して、オープンなウェブ技術を推し進めていくつもりだ」とのこと。その戦いを効率的・効果的に進めていくためにWebKitの採用を決めたということだ。

開発者と利用者の着眼点の違い

理想を言えば、さまざまなベンダーが「標準」に則った開発を行って、レンダリングエンジンの違いによる差異などを意識しないで済むというのが良いのだろう。同じコードは同じように表示されるべきだろう。しかし、「標準」を意識しつつも実装により細かな違いがあり、同じような表示を実現するなどということはできなかった。

但し、たいていの利用者はレンダリング方式の違いによるウェブページやウェブアプリケーションの見え方にはほとんど意識を払わなかった。利用者は利用可能な機能(ブックマーク、プラグイン、タブなど)によってブラウザを選択していただけなのだ。そうした機能の多寡や使い勝手によって、利用者はブラウザを切り替えてきたのだ(もちろんあまりに速度が遅いものなどは排除されることになる)。

Mozillaは、魅力的な機能を提供していくためには、ブラウザ全体を自ら手がけていく必要があると述べている。今やWebKitに対する唯一の対抗勢力と言っても良い存在になったMozilla陣営は、自らの言葉を証明するために、利用者にとって真に魅力的な機能を提供していく必要がある。

個人的には、「標準」に基づいた競合がある方がイノベーションサイクルも早まると考えている。ウェブ技術というのは、まだひとつのエンジンに集約してしまうような枯れた技術ではないと思うのだ。レンダリングエンジンが複数存在すれば、余計な作業も増えるだろうし、迷惑に感じられることすらあるかもしれない。しかし将来的にきっと実を結ぶ、「若い時の苦労」になると思うのだ。

原文へ

(翻訳:Maeda, H)

HTML5対応アプリケーションがオフラインデータを複数のデバイスに亘ってシンクできるAPIをGoogleが提供

chrome_canary

HTML5の便利なところは、Webアプリケーションがデータをローカルに保存できて、ユーザはオフラインでもそれを見られることだ。そしてGoogleが今日(米国時間2/15)披露したChromeの新しいAPI、SyncFileSystem APIは、HTML5のスペックにすでにあるものと似た、アプリケーション固有のサンドボックス的ファイルストレージシステムを提供する。このAPIのおもしろいところは、Google Driveによるクラウド上のバックアップサービスを利用して、複数のクライアント間でデータを自動的にシンクできることだ。

今このAPIが使えるのは、Chromeのきわめて実験的なバージョンであるCanaryにおいてだけだが、数か月後には通常の安定版Chromeにも実装されるだろう。

Googleも言っているが、これはデベロッパがクラウド上の任意のドキュメントにアクセスできるためのAPIではない。オフラインデータを複数のマシンにまたがって保存し、シンクするだけである。

そのドキュメンテーションでGoogleが標準的なユースケースとして挙げているのは、“ユーザが生成したデータ(やそのほかのバイナリデータ)をキャッシングなどの目的でローカルにオフラインで保存するが、アプリケーションがそのデータをクラウドのストレージに保存/シンクして、同じデータを異なるクライアントたちにも可利用にしたいとき”、だ。

現在このAPIは、バックエンドのストレージサービスとしてGoogle Driveだけをサポートするが、将来はデベロッパに、ほかのサービスも使えるオプションを提供するらしい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

グループビデオチャットのTenHandsがChromeのWebRTCで実装–プラグイン不要に

tenhands_logo

Webアプリケーションとモバイルアプリ向けにビデオコラボレーションサービスを提供しているTenHandsが、WebRTCのサポートを発表した。WebRTCはブラウザ内でプラグインを使わずにオーディオやビデオによる通話ができるためのJavaScriptライブラリで、TenHandsのAPIは、ユーザがChrome 24より上のブラウザを使っている場合には自動的にWebRTCによるオーディオビデオ通話を行う。

これまでの(そしてデフォルトの)TenHandsは、Chromeの場合のようにブラウザがWebRTCをサポートしていなければ、自分のWebRTCプラグインをインストールするので、デベロッパは相互運用性を心配する必要がない。しかしTenHandsは、いずれどのブラウザもWebRTCをネイティブでサポートする、と予測している。その標準規格化に関して、Microsoftだけは独自の考えのようだが、いずれにしても今すでにWebRTCの普及に期待しているベンダは多い。Skypeを抱えるMicrosoftも当然、このレースに加わるはずだから、向こう数か月の標準規格をめぐる議論からは目を離せない。

gI_78803_Screen Shot 2012-11-12 at 11.27.08 AM

TenHandsのCOO Jack Blaeserによれば、どのWebブラウザも標準規格として確定したWebRTCをサポートするようになれば、ビデオの民主化に向けての大きな前進になる。これからは個々のアプリケーションやベンダ(AT&T, Verizon, Skype, …)に閉じこめられることなく、どんなユーザでも、どんなアプリケーションでも、ブラウザの上で、HDビデオと音声によるコミュニケーションができるようになる。そのための特殊なハードウェアやソフトウェアは要らない。

Blaeserの見方では、それによって数々の新しいユースケースも生まれる。たとえばコールセンターは、Webでもモバイルでも、ビデオと音声でリアルタイムの対話ができるようになる。またWebRTCの標準化と普及により、遠距離学習や遠隔医療などがより簡単にできるようになり、イノベーションを加速する。“ブラウザが情報へのアクセスに革命をもたらしたように、WebRTCによってそのブラウザがさらに、ビデオと音声によるコミュニケーションのメインの手段になり、通信市場全体が大きく変貌する”。ということはつまり、これまでの携帯キャリアとか放送局〜放送会社など、大量の通信帯域を特定目的だけのために独占していた業態は、不要になると思われる。インターネットでも、Skypeに代表されるような私企業的規格に基づくアプリケーションは、おそらく御用済みになる。

TenHandsがさらに主張するのは、同社が“GoogleによるWebRTCの実装を利用する、初めての、Flashに依存しない、リアルタイムの商用ビデオソリューション”であることだ。ただし、TwilioPlivoTokBoxなどのビデオプラットホームもすでに、各種のWebRTCベースのサービスを提供している(多くはまだベータだが)。

TenHandsの創業は2011年で、それ以降今日まで、レーダーに映らない低空飛行を続けてきた。しかしこのところ、WebRTCがホットな話題になってきたので、同社のステルスモードもあと数か月で終わるだろう。Chrome向けの、ネイティブWebRTCによる実装のローンチを記念して同社は、2月9日にAPIのハッカソンを行う。優勝賞金は4000ドルだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Google Nowがデスクトップでも可利用に?: Chromeのコードに通知センターが加わる

richNotification

Google Nowはたぶん、ぼくがAndroidを好きな理由の一つだ。だから、Chromiumの最新ビルドにノーティフィケーション(通知)センターが載ったというニュースは、すばらしい。先月のChromeのコードの変更はGoogle Nowのカードが近くChromeに載ることを示唆していたから、ノーティフィケーション(通知機能)と合わせると*、いよいよGoogle Nowはモバイル以外の世界にも広がっていくようだ。〔*: 新しいGoogle Nowカードが掲出されるとユーザには通知アラートが行く。だから両者はセット。〕

通知センターに関するコードの変化を見つけたのはフランスのデベロッパFrançois Beaufortだ(The Next Webより)。Google NowのカードがChromeに載るらしいと思わせる最初の変化を見つけたのも、彼だ。実際に動かしてみるには、Chromeのためのオープンソースの開発パイロットというかテストベッドのようなChromiumを使う必要がある。そして、ブラウザの構成パラメータchrome://flagsで”Enable Rich Notifications”オプションをonにする(通知をon)。こんな面倒なことをするより、Chromeの正規バージョンを待ちたいというユーザがほとんどだろう。しかもノーティフィケーションセンターには今はまだ、わずかなものしかないからね。

これまでの通知機能はGoogle Nowにとってあまり便利じゃなかった。ノーティフィケーションセンターの導入で、Chromeの通知機能が大幅に改良される。つまりiOSのNotification Centerみたいに、通知が一箇所で集中管理されるのだ。最新情報が一箇所にまとまっているから、ほかの仕事をしながらでもほんの一瞬で更新情報をチェックできる。とりわけ、Chromebookのユーザには便利だ。

Chromiumで試行したことのすべてが、その後の安定バージョンのChromeに載るわけではないが、でもこれは、Google Nowのリーチを広げていく長期的な戦略の一環だろう。とくに、デスクトップではモバイルよりも多くのユーザ情報を集められるから、Google Nowにとっても、栄養豊富な環境だ。それに、デスクトップユーザにGoogle Nowの味を教えると、モバイルでも使いたくなるだろう。Chromeが正規にサポートして当然、とも言える機能だよね。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))