Google Gears：第二天的业界反应

作为 5 月 31 日的 Google 开发者日活动的一部分，Google 宣布了新的离线 Web 应用程序 API：Google Gears。在 FAQ 中，Gears 定义如下：

Google Gears 是开源的浏览器扩展，它可让开发者创建能离线运行的 Web 应用程序。Gears 提供以下 3 个关键特性： - “本地服务器”，缓存资源（HTML、JavaScript、图片等等），使应用程序无需连接服务器即可访问这些资源

• “数据库”，在浏览器内部保存和访问数据。
• “工作者线程池”，通过在后台执行费时的操作使应用程序响应更加迅速。

Gears 在新的 BSD 许可证下授权，使得Gears 运行时API 可以以最小的约束嵌入到第三方的软件中。目前的安装形式是浏览器扩展（大约700k 大小），支持Windows 下的IE 和Firefox，Linux 和OS X 下的Firefox。对于Opera 和Safari 的支持正在开发中。

让我们进一步的了解所提供的3 个组件：

本地服务器（LocalServer）

本地服务器是一个专用URL 缓存，它拦截请求并在需要时由本地对其进行响应。有2 种类型的URL“资源库”。其中，最基本的是资源库（ResourceStore），它允许应用程序保存那些与URL 关联的特定用户文件，如PDF 或图片。这些被缓存的URL 必须由应用程序显式更新。第二种资源库被称为受管资源库（Managed ResourceStore）。它包含一组由清单（manifest）定义的URL。当清单的版本号发生变化时，该集合必须被自动更新。Gears 会周期性的检查受管资源库是否被更新了。

数据库

除了URL 缓存，Gears 还包含一个 SQLite 数据库实例。数据库中的数据按照域名（Domain）分区，除了最初保存这些信息的域名外，从其它的域名无法访问这些数据。使用 Javascript 访问数据库的语法与 JDBC 非常类似：

resultSet = db.execute (<br></br> 'INSERT INTO MYTABLE VALUES (?, ?, ?) WHERE id=?',<br></br> [1, 2, 'three four', 5]);<br></br>while (rs.isValidRow()) {<br></br> console.log(rs.fieldName(0) + " == " + rs.field(0));<br></br> rs.next();<br></br>}<br></br>rs.close();

工作者池（WorkerPool）

Google Gears 提供的最后一个元素是工作者池 API。文档解释了包含它的原因：

在浏览器中，一个时间密集型操作，如 I/O 或重量级计算，会使用户界面无响应。工作者池模块在后台运行操作，因此不会阻塞用户界面。脚本在工作者池中运行，不会触发浏览器的“无响应脚本”对话框。

工作者池的行为象一组进程，而非单独的线程。除了 Javascript 函数，工作者无权访问 DOM。当工作者接受到响应时，onmessage回调被用于执行活动。

就 Google 自身 Web 应用程序中的最初使用来说，Gears 已经被集成进Google Reader ：

GWT 团队也已经装配了 Google API Library for Google Web Toolkit 。Gears API 集成利用了 GWT 的 JavaScript 本地接口（JavaScript Native Interface，JSNI）。

ZDNet 的 David Berlind 对 Google 的 Linus Upson 进行了采访，访谈中显示，Google 期望 Gears 能成为离线 Web 应用程序开发的标准：

Google 的 Upson 对于公司开源这一技术的动机并不加掩饰。按照他的说法，公司打算使它成为目前市场中的一个标准，而不是满足标准机构的需要。由于几乎没有 Web 应用程序提供商具备这种离线能力，加上 Google 为此准备了一笔战争基金，这一技术很有可能会成为离线运行的 Web 应用程序的事实业界标准。

作为这些努力中的第一步，Adobe 宣布支持 Google Gears。Berlind 的文章提供了更多细节，它们来自 Adobe 的 Michele Turner：

Google 抓住我们，并说他们将发布一种使基于浏览器的应用程序具备离线能力的技术，同时他们认为该技术与我们的 Apollo [运行时] 有某些牵连。因此，我们和他们一起坐下来进行了交流，如果你大致看看 Google Gears 的 3 个主要组件就会发现，我们正在开发相同的技术以促进 Apollo 运行时离线组件的开发。…因此，现在我们正与 Google 共同努力解决一些问题，例如为了具备离线能力，必须对 SQLite 数据库进行同步和异步调用。

作为集成的示范，Adobe 的Christophe Coenraets 构建了一个与Gears 集成的Flex 应用程序，它由Kevin Lynch 在Google 开发者日演示。在构建demo 时，Coenraets 还开发了SQLAdmin 来帮助他操纵Gears 数据库。

Google Gears 的声明同样也引起了关于 Dojo 离线工具集未来的推测。 Ajaxian 就此采访了项目的首席开发者 Brad Neuberg。他指出，在发表声明时 Dojo 正处于正常运转中，并且他已经使用 Google Gears 作为基础平台，并完成了 Dojo 离线功能的移植。要了解更多的细节可以去听他的访谈。

RedMonk 也详细报道了 Gears。Stephen O’Grady 就 Gears 对一些已存在的可选方案的影响进行了推测：

从一个应用程序提供商的观点来看，我倾向于 Berlind 意见，他说： > 对于已经提供离线架构的公司，如 Zimbra 有它的 Zimbra 桌面（它的离线能力借助了 Java），他们的问题核心在于：如果 Google Gears 获得了市场吸引力，那些公司可能被迫完全重新考虑那个架构。如果你是 Zimbra，并且你的资源是有限的，那么起码问一个关于是否继续投资一个多余的离线架构是否合理这一问题就很有意义了。它可能值得，这是从技术的原因来说，但它可能不值得。

如果你是 Joyent，问题就更复杂些。他们瞄准的是远比 Google Gears 特殊的小环境，用于 Rails 应用程序，因此问题将归结为 Slingshot 是否能为 Rails 的开发者提供足够多的专有特性，让他们决定使用它。将他们论点的折衷时发现：到目前为止，Slingshot 还没有象 Gears 一样在很多平台上可用。然而，他们看起来满足于扮演 David。 有趣的是，Adobe 似乎铁了心要和 Google 合伙，甘心将他们 SQLite 的成果与 Google 的成果合作。这对 Google 的最终目标来说是个好兆头。

随着离线 Web 应用程序增长的势头，以 Gears 和 Apollo 等的形式，Web 应用程序开发者不得不开始考虑"离线"对于他们的个体应用究竟意味着什么。 Basement.org 评论这个任务是“忘却学习（unlearning）”：

桌面范式：文件保存在我可以“获得的”文件夹中，工作然后保存，它非常强大…但是同样存在成本，它在于并不真的知道这个资产存放在哪儿。如何将它传给别人？如何删除？如何移动？当然，那些熟悉 2.0 主义的我们，将这些问题注销是没有理解这种“新的做事方式”的表现。人们理解文件的表示还没有那么快。对于每个人而言，文件 - 不论是电子表格还是文档、图片都有我爱说的“认知完整性。”… 看看设计者们将如何解决目前的挑战，即帮助用户掌握和利用当前发生的变迁，是非常有趣的一件事。在我们踏上征途之前，我们应该确信那儿的确存在价值，而且其价值大于不可避免将发生的忘却学习过程。

查看英文原文： Google Gears: Industry Reactions The Day After