转 - Google工程师谈Web的未来

http://news.csdn.net/a/20100123/216670.html

 

 

这是 Ars Technica 的记者 Jon Stokes 与 Ryan Paul 对 Google Chrome 操作系统的项目工程师 Matthew Papakipos， 公共关系部的 Eitan Bencuya 做的一次访谈，谈到了 Google Chrome 操作系统的孕育，现状与技术，谈到了 HTML 5 以及未来的 Web。这是第二部分，第一部分请参阅Google Chrome 操作系统开发内幕。

访谈者与被访谈者名字及简称：

• JS - Jon Stokes
• RP - Ryan Paul
• MP - Matthew Papakipos
• EB - Eitan Bencuya

Web 应用 vs 文档，以及 Web 的天性

JS:Web 存在这样两种模式，一种是文档，一种是应用，Google Maps 是应用，Ars Technica 是文档，但你们将文档和应用同时放到一个浏览器窗口中。

我知道你们仍在改进用户体验，我想知道的是，你们会停留在文档模式，还是向应用模式转换，这样，你们的应用将拥有类似 OS X 般的窗口，而不是现在网页的模样。

MP:你的问题很到位，现在的 Web 人有些古怪，它们中的大多数还是静态的内容，看上去更像文档，甚至CNN，The New York Times, Wall Street Journal 这样的站点仍是一些静态网页，虽然他们的内容是动态输出的，还包含广告，这本质上，是你从页面上阅读，而不像 Gmail， Picasa， Netflix 一类的站点，它们更像应用，你可以把一些东西拖来拖去，改变次序。

目前，在Chrome中，我们没有对二者作出太多区分，因为Web也不是按二者严格区分的，但我们开始在 Chrome OS 中做很多事，增加一些特殊功能，这些功能是真正的应用。比如，Chrome OS 中的 mailto 链接，通常，这类链接是打开浏览器外部的一个 Windows 邮件程序，但如果你使用 Gmail 这就罗嗦了。所以，我们在研究，如何能从当前的 Tab 直接跳到运行 Gmail 的 Tab 或窗口，或者，直接弹出一个写字板，这样，你就不会打断当前你正在浏览的东西。

所以，我们开始在这方面做研究，如何将不同的链接方式定位到不同的 Web 引用上。比如，如果我有一个 Web 版的 JPEG 图片查看器，如果有人在 Chrome 或 Chrome OS 设备中想打开一个JPEG 图片该怎么让它们关联起来？

还有一个例子，.doc 文件。如果我点击了一个 doc 文件，我是想在 Office Live 中打开，还是希望用 Gview 查看，抑或是把它存储到 U 盘？用户该如何告诉 Chrome 他想怎么处理？

JS:这似乎是 Windows 早期遇到过的问题，诸如 OLE，注册表之类，然而在 Web 上，这将是同样重要的问题，只不过环境不同。

MP:我希望用一种简单但灵活的方式解决这些问题，在 Windows 中，那是非常复杂的，不同的程序都想争夺某些文档的处理权，Quicktime 和 Windows Media Player 争斗，后者又同 Chrome 争斗，对用户来说，这很难处理，而现在的 Web 已经开始具备这种能力，你可以注册文件格式，我们在这方面是领先的。

你另一个问题是，我们是否将让这些应用看上去像 Tab 还是别的？目前，我们只是想让他们像 Tab 以及一些看上去不太一样的窗口，让它们全像 tab 似乎更好。

我一天当中绝大多数时间是活在浏览器中，每次当我不得不运行一些浏览器之外的应用时，都感到麻烦，所以我们希望让它们都保留在 Tab 中。但这都属于 UI 的层面，以后还会改变，我们面向消费的发布还在一年以后，很多东西都会改变，但那是我们目前的想法。

JS:Mailplane 在我们 Ars Technicia 非常受欢迎，你用过吗，或看到过别人在用吗？

MP:没有。

JS:那时一个对 Gmail 的包装应用，包含一些 mail 相关的饰件。

MP:在 Chrome 中有类似的东西，让 Gmail 使用特别的界面运行，在你的桌面上安装一个 Gmail 图标，就像传统桌面程序那样。

EB:任何网站都能使用传统桌面图标打开。

MP:Google Gears 能让你为一些应用创建桌面图标并让 Web 程序看上去像桌面程序。

EB:它是内置在 Chrome 中的，现在你可以直接用这些快捷方式打开 Gmail 或任何站点。

MP:...不使用那些 Tab 或按钮...

JS:对，有一个 Fluid 程序，可以将给定的 URL 转换为一个桌面程序，你见过没有？

MP:是，这就是他所描述的 Chrome 中已经拥有的一些东西，我想这些东西在传统操作系统中更适合。

JS:我想我这样说的意思是，我们已经有一些方法，让 Web 应用更像应用，这样，从用户体验的角度，他们在界面上和普通的应用一致，而 不是硬塞进一个 Web 文档，对我来说，这是好事，好过将所有东西都塞进浏览器窗口。

但这是一个很大的哲学话题。

MP:我想我们在 Chrome OS 中有办法把这两种概念融在一起。现在我们感觉有点古怪，因为我们这些浏览 Tab 是由浏览器管理的，而我们的操作系统管理不同的应用。在 Chrome OS 中，所有东西都是 Tab，我们可以让窗口管理器管理这些 Tab。

所以，从某种方式，事情应该变得更清楚，用户模式也变得更清楚。因为不再有两种不同的应用（桌面应用和 Web 应用 - 译者注），只有一种应用，如何展示这些将因时而异，要看哪种对用户更适合。

目前，我们在 Chrome OS 中有两种方法来处理，一种是，应用和页面作为 Tab，另一种是使用预览模式，可以看到多个 Chrome 窗口，你可以在不同窗口间挪动 Tab 和应用。

但我们正在研究，是否将这些东西称作 Web 应用，它们是否可以拥有更广的能力，比如处理文件类型和 mailto 链接。

程序细节

RP:从程序员的角度，我关心这样几件事，特别是，是否有办法使用诸如 NACL 的东西编写本地代码，实现浏览器和应用之间的接口？Google 是否考虑将 NACL 一类的东西纳入 Chrome OS？

MP:是，确切无疑，我们计划这样做。

RP:是否已经有了一些原型？

MP:Chrome 本身就是。你现在使用某些特殊参数运行 Chrome，可以调用一些实验性的本地客户内容。

不过在具体发布之前，这些还会有变动，在稳定发布版的 Chrome 中还没有，还存在一些安全问题，在解决这些问题之前，我们还不想默认打开这些功能。但这些都确切无疑在进展中，还且肯定会包含在 Chrome OS 中。

RP:是否有计划将硬件访问通过 JavaScript 暴露给诸如 NACL 一类的东西。

MP:你说的硬件访问是什么意思？

RP:比如，如果有人想访问摄像头或 GPS，我知道现在已经有一些像 geolocation 之类的 API，但其它那些还没有被 Web 标准所支持的外设呢？

MP:这个问题很好。我们正寻求将那些设备加入到 HTML5 API 中，以便可以通过 JavaScript 访问，或者通过 C++ 在本地客户中访问。

你是对的，我们仍有大量的工作要做，如果让我把那些设备清单列出来，那我们现在需要做的有声音设备，摄像头，麦克风，线路输入等，另外，我们还没有 像杜比5.1声道那样的东西，P2P网络，甚至连客户端-服务器这样的 API 都少得可怜，这些东西，我们都在做。

这是很庞大的工作量，让 JavaScript 和本地客户访问这些 API 还有待时日，但我们尽可能加快速度。

RP:那你们是否有计划在 Chrome OS 中加入 Dalvik 运行时，这样人们可以运行 Android 程序？

MP:还没有。我们主要将精力放在 Web 应用层面。不过，我们的本地客户是一个很好的东西，我个人为之振奋，但我们对用户的期待也要抱务实态度，那还有待时日。

JavaScript API 也是一样，我们希望有 JavaScript API 可以访问摄像头或麦克风，但必须考虑安全问题，用户是否接受？如何防止某些网页 Tab 在你穿着泳衣的时候通过摄像头偷窥你？这些问题很棘手。

EB:当然，我们将以一种开放的方式来做，但这需要时间。HTML5 也需要时间。

Web 应用的优先级和权限

RP:我还想问，有没有办法让某些 Web 应用获得高优先级？

MP:这颇不容易。现在的操作系统是这样做的，有明确的 ECLs 和权限分配，我们从传统操作系统中学到的教训是，用户很难对它们进行管理。

如果和 Web 模式比较，Web 的观念是，你不应该在 Web 应用中做任何不好的事，这个观念让 Web 运行得很不错，你浏览 Web 的时候，一般不需要担心会出现不良的东西（译者注：作者这里是从应用的角度讲），尽管有浏览器漏洞和恶意软件，但总体是不用太担心的。

我们尽量避免传统操作系统中的 ECL 及许可列表的问题，所以我们很谨慎，但我们确实在努力实现。geolocation UI 是我们目前做过的最难的东西，这个 UI 很棘手，需要非常谨慎，因为你不能泄露用户的地理位置，虽然你可以让用户选择是否向网站暴露自己的地理位置，但必须做得让人愉快一些。

现在的一些手机，如果你访问一些使用了 HTML5 Geolocation API 的站点，会不断弹出窗口，问你是否愿意提交自己的地理位置，这很烦人，有时候，人们习惯了一率点是，这回很危险。我们必须研究出怎么做，要做得简单，不那 么烦人，但目前还没有答案。

一般来说，浏览器处理这种事情是通过信息条或对话框，但我们更趋向于使用信息条，因为对话框会锁住浏览器，直到你作出反应，这会降低用户体验。因 此，很多浏览器，包括 Firefox 趋向于使用信息条显示提示消息，你可以做出反应，也可以不理会继续浏览。

比如，Chrome 在提示你记住用户名和密码的时候，会将消息显示在消息条上，我们在许可配置这些 UI 问题上，趋向于这种模式。

对 Chrome OS UI 进行扩展

RP:在对 UI 和 操作系统进行扩展方面，似乎 Chrome 扩展是主要的方式，是吗？

MP:对 Chrome 浏览器来说，是这样。

RP:对 Chrome OS 来说，是否有计划增加其它扩展方式？比如，针对不同平台定制功能？

MP:我们还没想到，不过这是个有趣的想法，你是否有具体的想法？

RP:我不知道，我只是在想菜单问题，在宽屏幕上网本上，增加侧边栏，虽然在常规的浏览器上，这没什么用，但在一个以浏览器为主题的操作系统中，这或许有 用。

MP:这个想法很好，确实，当我们浏览网站的时候，屏幕两边都有很多空白空间，我们可以在这些地方放置侧边栏， 我们已经在 Chrome OS 中考虑侧边栏 UI 问题，做一些试验，侧边栏放在什么位置，我们不断调整，我们有200 多 Google 试验者每周都使用 Chrome OS设备，我们经常在里面加一些新东西，看看他们是否经常使用，通过这些试验，我们不断迭代。

本地应用 vs Web 应用问题

MP:Ryan，我想听听你对 Chrome OS 的看法，是否有一些东西在你看来是古怪的？

RP:我抱一种走着瞧的态度，我觉得有很多变数，主要的问题我觉得是，相对于那些基于常规操作系统的 Chrome 浏览器而言，Chrome OS 能给用户带来什么价值？

在将所有东西都纳入浏览器这件事上我仍然有点疑虑，我们看看现在的一些 Web 应用，他们相反正将在提供一些桌面版，如 Twitter。

我在想，如何只靠浏览器实现全部这些需求。

MP:嗯，是，如果有一些东西浏览器不能实现，我们会对浏览器进行扩展。

JS:那就是前面谈论我们谈论的 Fluid 和 Mailplane 应用。

MP:我仍然认为，我们应当看着这些应用，并想到，为什么它们必须是本地程序，我们可以增加一些功能来实现。一 个很好的例子是，很多本地程序可以在后台运 行，于是人们希望在 Web 程序中实现后台进程，比如，在 HTML5 中实现后台上传文件，这样就不必浪费一个 Tab 并让浏览器开着。

EB:还有提示消息，在 Twitter 的桌面程序中，每当你收到一个新 Tweet，就会给你一个提示消息，在浏览器中，也有 notifications API 实现类似的功能。

MP:我们还在研究上传问题，因为上传是很常用的用例，当我向 Picasa 上传照片的时候，我们必须开着一个 Tab 或者安装一些复制程序，我们需要研究出一些方法让这些功能内置在 Web 中。

内置的媒体播放器

MP:还有媒体播放器问题。我们将一个完整的媒体播放器集成到 Chrome 浏览器和 Chrome OS 中，人们常常为此困惑，这很微妙，但非常重要，因为从某种意义上说，我们是在将一个相当于 Windows 媒体播放器的东西集成到 Chrome 中。

在普通电脑中，我们需要一定的方法来离线播放 JPEG， MP3 和 PDF 文件，比如，如果你有一个 U盘，上面有 MP3 文件，你可以插上去，听那些音乐，并没有对应的网页来控制这些，我们做了很多工作，在 Chrome 和 Chrome OS 中处理这些用例。

RP:你们的方法是标准的，基于 HTML5 的视频和音频吗？

MP:是的，绝对的。

RP:你们会让 Video 标签支持更多编码吗？

MP:我们并不是单单增加一些编码那么简单，而是为整个 video/audio 标签提供方案，因为 video/audio 标签的设计是针对网页的，比如像播放网页上的某个媒体，但如果你有一张 U盘，想播放上面的 MP3 文件怎么办？你如果浏览到那些文件并对它们进行播放。

再比如，如果在 Gmail 中收到邮件，上面有 MP3 文件，你不应当退出 Gmail 在外面播放那个文件，我们希望直接在 Chrome 里面播放，而且整个过程要十分清晰。

这就是我们在 UI 层面的重要事情，将整个媒体播放器集框架集成到浏览器，这并不稀奇，因为别的浏览器也在这样做过，但 Chrome 之前没有。

本文国际来源：http://arstechnica.com/business/news/2010/01/chrome-os-interview-1.ars/
中 文翻译来源：COMSHARP CMS 网站内容管理系统官方站