开源的Google Gears欲成新的市场标准

来自：InfoQ
         作为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必须由应用程序显式更新。第二种资源库被称为受管资源库（ManagedResourceStore）。它包含一组由清单（manifest）定义的URL。当清单的版本号发生变化时，该集合必须被自动更新。Gears会周期性的检查受管资源库是否被更新了。

      数据库

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

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

      工作者池（WorkerPool）

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

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

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

　　就Google自身Web应用程序中的最初使用来说，Gears已经被集成进Google Reader：
[img]http://www.lupaworld.com/attachments/2007/06/22802_200706110916081.jpg[/img]
　　GWT团队也已经装配了Google API Library for Google Web Toolkit。Gears API集成利用了GWT的JavaScript本地接口（JavaScript Native Interface，JSNI）。

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

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

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


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

　　作为集成的示范，Adobe的ChristopheCoenraets构建了一个与Gears集成的Flex应用程序，它由KevinLynch在Google开发者日演示。在构建demo时，Coenraets还开发了SQLAdmin来帮助他操纵Gears数据库。
[img]http://digitalbackcount.setupmyblog.com/wp-content/uploads/2007/05/christophe_sqladmin.jpg[/img]
　　Google Gears的声明同样也引起了关于Dojo离线工具集未来的推测。Ajaxian就此采访了项目的首席开发者BradNeuberg。他指出，在发表声明时Dojo正处于正常运转中，并且他已经使用GoogleGears作为基础平台，并完成了Dojo离线功能的移植。要了解更多的细节可以去听他的访谈。

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

　　从一个应用程序提供商的观点来看，我倾向于Berlind意见，他说：

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

　　如果你是Joyent，问题就更复杂些。他们瞄准的是远比Google Gears特殊的小环境，用于Rails应用程序，因此问题将归结为Slingshot是否能为Rails的开发者提供足够多的专有特性，让他们决定使用它。将他们论点的折衷时发现：到目前为止，Slingshot还没有象Gears一样在很多平台上可用。然而，他们看起来满足于扮演David。

　　有趣的是，Adobe似乎铁了心要和Google合伙，甘心将他们SQLite的成果与Google的成果合作。这对Google的最终目标来说是个好兆头。

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

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