Environment: Linux mail 2.6.27.7-smp #2 SMP Thu Nov 20 22:32:43 CST 2008 i686 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux

Q: PHP configure utility reports that there is no IMAP support on my system.

A: According to PHP Manual: IMAP Installation, I need to get something named c-client, and compile PHP with --with-imap[=DIR].

Q: Where to get c-client?

A: Googled answer IMAP Information Center: The software and documentation is available at ftp://ftp.cac.washington.edu/imap. UW IMAP toolkit source distribution is available at ftp://ftp.cac.washington.edu/mail/imap.tar.Z.

Q: So strange a package, how to make and install?

A: Normally, you should run configure, make and make install to install a package from source, but no configure found and make is different.

First, make sure you have OpenSSL installed, and then follow the setps:

Extract the archive downloaded to /use/local, folder named imap-2007e

NOTE:

If you like me discover that "make slx" fails, but you're damn sure you've openssl installed then, it might be that the lib and include paths on your distribution are different then the defaults provided in the imap-2007e (or imap-XXXXx). To modify go to dir src/osdep/unix and edit Makefile, around L55:

1. # Extended flags needed for SSL.  You may need to modify.
2.  
3. SSLDIR=/usr/local/ssl
4. SSLCERTS=$(SSLDIR)/certs
5. SSLKEYS=$(SSLCERTS)
6. SSLINCLUDE=$(SSLDIR)/include
7. SSLLIB=$(SSLDIR)/lib
8.  
9. SSLCRYPTO=-lcrypto

Change SSLDIR, SSLINCLUDE and SSLIB to valid paths for Slackware. In my case, it should like this:

1. # Extended flags needed for SSL.  You may need to modify.
2.  
3. SSLDIR=/etc/ssl
4. SSLCERTS=$(SSLDIR)/certs
5. SSLKEYS=$(SSLCERTS)
6. SSLINCLUDE=/usr/include/openssl
7. SSLLIB=/usr/lib
8.  
9. SSLCRYPTO=-lcrypto

You should also check your ld.so.conf for valid paths.

Q: How to compile PHP w/ IMAP support?

A: Finally, we've reached the last step. Re-compile PHP and everything is done. When configuring, just add those two imap options

Bing! Your system is ready for your imap application.

今天是3月份第一天，应该有个好的开始。

00:00-01:00 为了这个好的开始，决定早早睡觉早早起床，结果因为一通电话，打完了居然精神了，睡不着了；

01:00-02:00 睡不着觉就顺便整理一下柜子里乱七八糟的东西，结果把一个纸箱子放到柜子上面的时候居然砸到手了；

03:00-04:00 躺床上发现晚上的网络不错，进校速度都很快，那么就把 HP 的服务器的最后一步配置完吧。一切顺利，Httpd、MySQL、PHP、SVN、FtpD 都配置的非常好，甚至 FtpD 的虚拟账户都配置的很完美。结果手贱非要把 svnRoot 目录改名为 svn。然后不小心把缓冲区的数据都发到了 console 上，不知道是哪辈子的数据，里面居然有一个分号，好死不死的是分号后面居然跟着 rm -fr /home！一个星期的心血就这么木有了……

04:00-05:00 算了，什么都做不了了，睡觉吧；

05:00-06:00 睡觉；

06:00-07:00 睡觉；

07:00-08:00 睡觉；

08:00-09:00 睡觉；

09:00-10:00 睡觉；

10:00-11:00 到办公室测试才下载的 VMWare ESXi Server。还特意申请了一个 HP 的本本来做一个全新的安装。开始启动……初始化……进入引导……啊哦，居然说偶只有 512M 内存，直接拒绝安装，就这么赤果果的被鄙视了……NND，老子想装俩 DOS 丫有意见啊！

11:00-12:00 恩。不过偶的 DELL 的工作站配置还不错。那么在工作站上用 VMware WorkStation 虚拟出来一个服务器装 VMware ESXi Server 再装虚拟机吧。哈哈，我是天才。划分了 2CPU w/ VT support、4G MEM、100G SCSI HDD 给虚拟服务器用，应该够吧。继续启动……安装……初始化，很顺利的成功了，赞一个；

13:00-14:00 研究怎么用这个 ESXi Server，下载安装必要的软件，划分好分区，把 ISO 拷贝过去，开始安装。Damn it！居然说不能再虚拟机里面跑虚拟机！NND！丫既然不让这么折腾，倒是早说啊。为什么不在安装的时候就提醒我啊；

14:00-15:00 算啦，不折腾了，决定用华丽丽的 19 寸的屏幕看以前攒下来的电影吧。就看那个布鲁斯南的《天崩地裂》好啦。老片子了，不过补习一下也不错。CD1实在是无聊，情节老套，特技虚假，主角无敌，配角闹事，男主角单身，女主角寡妇……太恶俗了吧；

15:00-16:00 一边看 CD2 一边远程控制服务器。输入那些熟悉的不能再熟悉的命令，咦，怎么没反应？哦，窗口焦点在 KMPlayer 上，刚才输入的命令都被 KMPlayer 截获了，不过……我输入的那些命令怎么和 KMPlayer 的快捷键一样？结果导致播放器字幕模糊，影响变形。都不知道怎么调回去。关了重开吧。咦，这个片子怎么压缩的，居然不能拖！

16:00-17:00 CD2 前半段又看了一遍，等到 30min 左右快要进入结局的时候，居然提示视频压缩损坏！根本播放不下去；

17:00-18:00 突然发现午饭没吃，早饭就吃了两个小面包，饿了。准备去觅食+逛超市。路过一个镇江面馆，进去吃面吧。居然没有偶要吃的面，真是不顺。去超市刷卡，发现还差两块钱凑 CMB 积分，要不要再买条口香糖？还是节约过日子？赚积分痛苦啊……

18:00-19:00 回到机房，准备重装。反正 /home 下面已经都被 rm -fr *了，直接重装吧；花了半个小时格式化 300G 的 SCSI RAID 硬盘后，才想起来 /root/ 下面还是有点东西需要备份的；

10:00-20:00 不过想起来模式动物中心机房的 100.7 的服务器上有这些数据的备份，还好，可以松口气了；100.7 在内网，访问不到，只能通过 100.1 跳过去，不过怎么在 100.1 上 ssh 不过去呢？ping 一下发现丢包率超过了 80%！

20:00-21:00 看来是网络问题了，打电话给模式动物中心机房的网管，结果说不在所里，只能等明天再说了……

21:00-22:00 回家。逛超市的时候准备安慰自己+超市特价买了一堆零食酸奶。开始犒劳自己。恩，那个什么粟米棒还不错，就吃多了口渴。喝下酸奶一大罐，没用，喝了一壶水才好受点；

22:00-23:00 困了，准备上床，刷牙的时候发现洗脸盆的下水管道堵了，拿个皮搋子搋了半天才弄好；

23:00-00:00 搋了半天下水管，加上刚才喝的一大壶水，睡不着了……开始失眠……

Read It Later Comes To Google Reader

Read It Later，一个流行的 Firefox 插件，最近发布了升级版本，该版本给 Google Reader 增加了一些新功能。这个新扩展同时兼容 Firefox 和 IE，这个新扩展让你能够在阅读你所订阅的 RSS 种子的时候勾选出需要稍后再做详细阅读的新闻，以此来加快你的浏览速度。 你还能够使用任何浏览器访问到这些你想稍后阅读的这些新闻，不管是在家里的 Firefox，在单位的 IE，甚至你的 iPhone 手机都可以。

这个升级版的 Read It Later 扩展给你的 Google Reader 的种子列表增加了一个 Greasemonkey-esque 功能，就是在每个新闻条目的旁边，星标的右边增加一个对勾符号。在你浏览你的订阅的时候，你勾选上的帖子会自动增加到你的阅读列表中——你可以随时在 readitlaterlist.com 网站上访问到你保存的阅读列表。通过内置的离线浏览功能，你还能在准备要离开网络的时候，下载一系列文章供你以后阅读——比如说当你乘飞机旅行的时候。

如果你使用书签插件来管理你的阅读列表，那么现在你有更多的选项供你定制。你可以使用“普通”模式或者“紧凑”模式查看阅读列表、选择每页显示的条目数、是否在侧边栏打开阅读列表、以及是否启用上下文关联菜单和附加的工具栏按钮。

不过，新加的功能中最棒的就是可以按照 PostRank 对阅读列表进行排序。我们在读写网好几次都非常关注这个曾经名为 AideRSS 的功能。在启用 PostRank 后，你的阅读列表会智能的按照流行度进行过滤。 有几种方式给一个帖子打分，包括该帖子收到的评论数、在美味书签上被标记的次数，被 digg 的次数，以及被引用的连接数。 你现在可以按照帖子的重要程度来浏览你的阅读列表，这对那些被过量的信息所困扰的人特别有用。

该插件还有一些其他的改进，例如升级了的隐私控制、现有功能的更强大技巧等，这些改进让 Read It Later 逐渐成你的浏览器中一个重要的插件，不管你用的是 Fireofox 还是 IE。 现在，我们就只需要的就是能够在 iPhone 上使用的书签插件，那就就齐活了。

Popout

想去中国游览紫禁城又买不起机票？现在，你只要有台计算机就行了。IBM——虚拟世界最忠实的信徒——和中国故宫博物院共同把这个占地 178 英亩的紫禁城在虚拟世界里重现。在三年时间里，他们非常细致的重建了所有的建筑物和数以千计的重要文物，现在，“超越时空的紫禁城”已经可供下载(有 Windows、Mac 和 Linux 版)。这个软件可以免费下载，不过先提醒你，Mac 版的可是一个实实在在的 275M 的安装包。

当你进去后，你能够选择你的形象、穿上清朝的服装、进行虚拟的浏览、和计算机控制的角色玩耍、查找地图、浏览建筑物和里面的文物，你还可以点击这些建筑物或者文物以得到进一步信息。这个虚拟世界构建在名为 Torque 的游戏平台，这个游戏平台来自 Garage Games。（我估计是因为 OpenSim 不够好，因为没有评论说虚拟时空紫禁城时候会和第二人生进行互动）

如果你想找个地方躲避现在金融风暴，但是有没钱真的出去旅游的话，那么你可以来 IBM 的超越时空紫禁城里闲逛上几个钟头。

但是此鼠娘家罗技泰克所附送嫁妆 SetPoint 乃伪劣产品，不得博得洒家新欢 Microsoft Windows 2008 之欢心，2008 不认其名门出身，只当是一 HID compliant Mouse，真是狗眼看人低，微软看鼠卑啊。

SetPoint 迫东家 2008 的于淫威，亦不敢主仆相认，就是不敢显示出那欲说还羞的 My Mouse 选项卡。

借古狗洋大人之力，终于在无尾鼠娘家旁边的一个老爷们扎堆聊天的地方找到了前人留下的洋文名帖一张，将藩语译成我中华之文字，方懂上书意思是，喜新厌旧是罪过的，有了新老婆 2008，不能忘了二老婆 Vista 和小妾 XP，须到二老婆或者小妾房中寻得名为 CDDRV2 的仙丹一枚给新老婆服用才可解除新老婆的障眼之疾。

虽说此方甚好，可以药到病除，但是难为了吾等洁身自好，二老婆小妾皆无之人，难道为了这个还要纳上一房不成？未免荒谬。再看前述之帖，此洋鬼子上留蝇头小楷一行，曰，吾等清白之人之赤心，上可达天庭，故玉帝命他将仙丹藏于一个名为 RapidShare 之八卦炉内，以诚心猛击此链接即可得仙丹。

洒家于是踏上 NJU_BRAS 大道前去寻访仙丹，不曾想，好事多磨，玉帝说 BRAS 戴着不爽，遂令如来将 BRAS 大道缩成极小，以难为用 BRAS 取经之人。无奈之下，退回来继续用 PROXY 小道，道上无人阻碍，方能够到达藩国按洋鬼子之指点找到仙丹，取回，用 LDPINST.exe 做药引给新欢 2008 服下，之间电光火石之间，2008 立马认出洒家的无尾鼠出自罗技泰克名门，立即取名为 Logitech HID compliant Cordless mouse。此时寻到 SetPoint，SetPoint 一看婆家已经接纳此鼠，亦显现出 My Mouse 以和之。

至此，洒家魂牵梦绕之 My Mouse 终得拨云见日，吾等方能用上左手鼠标。善哉善哉。

口说无凭，立照为证：

附上新鼠未嫁之前之裸照一张：

附上洋泾兵之贴：Windows Server 2008 x86(32bit) + Setpoint 4.6 installation ，后来者请自去寻访仙丹。

五花肉糜、四川甜面酱、香菇丁、葱花熬得如此炸酱，可惜南京找不到六必居的干黄酱买，口味大打折扣……虽然还是那么好吃。想起来小时候帮厨的时候用水去化那个像便便一样的美味的干黄酱的情景了。

配上黄瓜丝，清脆可口，不过偷懒，没有自己手擀面，市场上买得机制手工面，聊胜于无。

右上角是室友赞助的干瘪小葱（买了块一个星期了）拌老豆腐，撒花～～～～～

顺便翻出来上个星期的芝麻酱凉面配剁椒木耳：

开拌前的：调好的芝麻酱一小碗，陈醋蒜泥一小碗，过水凉面一晚，黄瓜丝半根。

拌好的样子，不过芝麻酱的颜色很浅，看得不是很清楚。

剁椒木耳，木耳香脆，陈醋微酸，配上剁椒蒜泥，简单美味。

问了其他的几个用 RSS Reader 的朋友，都木有这种问题，怪哉。

RSS Reader 自动跳转……仔细看地址栏、Tab 标签标题和状态栏……

跳转后的 Slides，真丑……

以前用的几种解决方案：

• 不写 href，这样会导致很多浏览器不会把 a 标签按照你预期的方式渲染；
• 在href 里面直接写 JavaScript 脚本，这样不完全符合 W3C 的规范。

其实要解决这个问题，不让浏览器把页面滚动到最上面，很简单，href="" 里面 多写几个 # 就行了，我一般用 6 个比较保险，这个方法适用于 IE5、IE6、IE7、FF2、FF3。虽然不知道为什么但是很好用。猜测是因为 # 表示进行页内书签的跳转，但是多个 # 浏览器就不知道什么意思了，干脆罢工好了，哈哈。

随着地图聚合给最终用户提供的一系列更广泛的工具和应用程序，它在完善程度和功能性两方面逐渐走向成熟。 因此，我们需要一些预定义好的方法在传统的地理空间数据和新一代的地图聚合之间交换、发布这些地理空间数据，并且使用一种对 web 友好的方式使用这些数据。

为了满足这种需求，出现了一些新的地理空间数据格式，这能够让更大范围的用户和开发者来聚合地理相关的信息。 下面是当前可供从事地理信息聚合的开发者使用的三种主要数据格式的一个概括：

KML

你知道 Google 地球的前身，那个流行的名为 Keyhole 的三维地球浏览器吗？ 如果你知道，那么这个基于 XML 的，Google 地球自己的文件格式被叫做 KML，意为 Keyhole 标记语言，就不值得惊讶了。 在地理空间相关的网站上，KML 无处不在，KML 支持从类似 Google 地图、微软的虚拟地球这样商业化的地图 API 和 OpenLayers 这样开源的地图 API 中导入、导出数据。 今年早些时候，Google 把 KML 作为一种开放标准发布，并且被开放地理空间联盟 (OGC) 采用。 你可以研读最新的 KML 规范 (当前是 2.2 版) 或者学习如何让 KML 与 Google 地图 API、虚拟地球或者 OpenLayers 集成。

GeoRSS

GeoRSS 提供了一种在 RSS (或者 Atom) 种子里通过特定的编码来包含地理参考信息的方法。GeoRSS 站点上说：

RSS 和 Atom 作为一种发布、共享信息的方法，正在逐渐流行起来， 因此，使用互操作的方式描述位置信息，来让程序能够请求、聚合、共享、地图化地理标记过的种子变得益发重要。

嵌入 GeoRSS 非常简单，仅仅在每个条目中增加一个类似 <georss:point>45.256 -71.92</georss:point> 这样的元素就行了，这里使用的是简易GeoRSS 格式， 如果要需要复杂完整的编码格式，可以选择支持更多的特性的 GeoRSS-GML 格式。这两种 GeoRSS 格式都支持基本的地理特征 (点、线、边框和多边形)。 和 KML 一样，商业化的地图 API 和开源地图 API 都支持 GeoRSS，并且主要作为导入数据的格式使用。 GeoRSS 许诺对整合内容的会有更好的支持。

GeoJSON

GeoJSON 是基于 JavaScript 对象表示法 (JSON)的一种新的数据格式，用来对大量的地理特征进行编码，支持的地理特征有点、线、多边形、多多边形和地理信息集合。

{ "type": "Point", "coordinates": [43.542, -118.454] }

GeoJSON 可以被 JavaScript 简单、快速的解析，而且 GeoJSON 还提供了一个可以很容易的进行交换的轻量级数据格式。 自从 GeoJSON 正式发表 1.0 版后，GeoJSON 的魅力逐渐增加，得到了包括 FireEagle 和 OpenLayers 在内的一些流行的 API 的支持 (但是不确定将来是否能够得到类似 Google 地图或者虚拟地球这样的商业 API 的支持)。

注意 GeoRSS 和 GeoJSON 都采用创作共用授权协议授权。

我们饶有兴趣的看着这些格式如何发展，而且很想知道类似 GeoRSS 和 GeoJSON 这样的格式能否得到地图 API 和地图聚合开发者的采用。

生成的 PHP 代码中该字段的默认值是 'null' 而不是 null，导致页面输入框的默认值不是空值，而是一个字符串的 null，很恼火。因为要么在页面中每个字段都对 'null' 做特殊处理，要么修改生成的 PHP 类文件，但是一旦重新执行 propel-convert-xml-schema 就会重新覆盖。

解决办法：修改 propel-generator/classes/propel/phing/PropelCreoleTransformTask.php 文件（对于 Symfony 来说，就是 symfony/vendor/propel-generator/classes/propel/phing/PropelCreoleTransformTask.php）。应用如下 patch：

参见：#2045 (propel-convert-xml-schema generate null text as default values) - symfony - Trac。

下载：PropelCreoleTransformTask.7z。

PEAR 中的 Structures/DataGrid 倒是不错。但是两个问题：无法和现在偶使用的 sfSmartyView 直接结合，因为在 $datagrid->fill($smarty); 的时候，symfony 还没有生成 view instance，除非直接获取生成的 HTML_TABLE 或者类似的结果，这样不利于 MVC 的分离和对具体样式的控制；二是现有的 datasource 无法和 symfony 使用的 propel 直接结合，如果采用检索全部结果再传递给 Structures/DataGrid 进行分页处理，那么效率非常低下。

于是自己写一个 datasource，并且使用了一点技巧解决和 sfSmartyView 结合的问题。

Structures_DataGrid_DataSource_Propel 类的定义：

action 中的代码段：

模板中的处理：

• SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account
  结果 29
• SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account LIMIT 10
  结果 29
• SELECT COUNT( sys_uia_account.ID ) FROM sys_uia_account LIMIT 10 , 10
  没有结果

看来以后使用 COUNT(*) 的时候不能同时使用 LIMIT offset, row_count 这种表达方式了。

PS：如果统计全表记录，使用下面的方法会更加快捷：

唯一需要注意的就是，这两个查询必须在一起进行，因为 SQL_CALC_FOUND_ROWS 不对结果进行任何缓存。

实例代码：

数据库表结构：

测试环境：Windows 2003 Standard Edition，MySQL 5.1.22-rc-community。

对于偶正在使用的 Symfony 框架，因为使用了 propel 做 ORM，比较难直接操作SQL，除非使用 RAW SQL，而且使用 RAW SQL会导致很多高级特性无法使用，解决方式：

Beata 和 RC 不支持吧。还能说是 bug，今天正式版发布，居然还是不支持，这就说不过去啦。用 Firefox 内嵌的 addons 管理机制安装 Flash 从来就木有成功过。

最后用如下方法才安装成功：

1. 下载 Adobe 官方的 FLash 卸载程序；
2. 下载 Adobe 官方的 Flash 安装程序；
3. 关闭 Firefox；
4. 运行卸载程序，再运行安装程序；
5. 如果有必须要，则重建 Firefox 插件数据库。

最后一步不是必需的，至少偶就木有用到。

现在终于能够看到满屏的 Flash 了……下一步，安装 flashblock 插件屏幕它们～hiahia～～

参考：FIrefox 3 and Flash pluggins 。

Google 在去年五月发布了 Gears，之后的一年里 Gears 被认为是一个小众产品，只会有很少开发者和用户用它来开发能够离线访问的 web 程序。兴许你还能回想起当年的争论：在到处都有网络连接的情况下，究竟谁需要离线访问功能，而且还没有足够的程序支持，等等。不到一年的时间，就在几周前，Google 亮出了他的王牌：Gears 助力 MySpace 加速邮件系统。其实 Google 早就加入了这场提供新 web API 的比赛，但是居然一年了都没有人注意到。

将来的浏览器很可能会变成运行所有程序的虚拟机。在这种情况下，操作系统会变的透明，就像 Adobe 所作的，它的 Flash 技术是现在使用的最普遍、最统一的 web 虚拟机，而微软则要自保（它的利润的来源）了。Google 不隐瞒他们想瞄准并且攻击微软的野心，他们知道，要做到这点的最好方法就是上移一层把操作系统架空，让浏览器成为标准且强劲的应用程序虚拟机。

很难在一片评论里表达清楚 Gears 如何改变并且增加 web 程序的功能。以前使用基于浏览器的 Javascript 脚本，MySpace 中的一些类似邮件列表和排序、根据好友列表过滤这样的功能会让人感觉很慢，而当浏览器向服务器发送多个请求时，进度条还可能会定住，沙漏图标在不停的旋转。而现在，安装 Gears 只要在确认框点击一下并且等待几秒钟，安装之后，以前让用户抓狂的那些功能现在感觉起来就好象是浏览器自带功能一样。Google 给我们秀了一把 Gears 与 MySpace 集成后的能力，这唤醒了大部分人关注他真正的意图：不再仅是离线浏览，而是直接针对 Adobe 和微软所采取的行动。

截至目前为止，Google 拥有一系列共计 28 个基于 web 的程序, 这些程序在全世界有数百万的用户。Google 开发 web 程序的技术都是基于标准的 HTML、CSS 和 Javascript。选择 Ajax 仅仅是因为这是最好的解决方案，但是 Google 还要做更多以面对现实，那就是每个类似的 web 开发技术体系都是被一个直接的竞争者所开发、控制。Google 对开源浏览器 Firefox 的开发给予了强大的支持，并且支持开放 web 标准作为他们的技术体系之选。Google 这么做是因为他们的 web 程序都依赖于开放标准，Firefox 的失败会导致 Internet Explorer 复生并且把 web 的控制权拱手让给微软。

以前，只用基于浏览器的 Javascript 来支持 web 程序对 Google 来说不是个问题。直到竞争者领先一步发布了他们自己的第二代 web 平台，分别是 Flex/AIR 和 Silverlight，情况才发生了变化。基于 web 的程序在有了类桌面的界面和功能后能够做什么，从这一方面开说，微软和 Adobe 已经超前了一大步。用不了多久，大大小小的竞争者就会使用竞争性技术平台创建竞争性程序，那会使 Google 的产品看起来像是还停留在上个世纪九十年代的样子。

留给 Google 的选择现在很明了了：要么放弃使用基于浏览器的 Javascript 和开放标准进行开发，转而接受新技术中的一种，要么继续坚持使用核心 web 技术并且发展这些技术直到成为可行的替代技术。Google 的问题是，新标准和预期的浏览器功能很快就会带来富 web 技术，但是开发那些标准的进度却如此缓慢，以至于很可能需要几年时间才能看到那些标准被广泛的应用。新的 HTML 标准，HTML5，特别关注扩展本地浏览器对 web 程序的支持能力，在不用附加私有运行时的情况下。Google web API 的基础就是这些同样的功能以及其他的附加功能。

由于标准开发的极其缓慢，导致通向更快更好，而且仍旧免费开放的 web 程序之路被堵死了，所以 Google 决定通过 Gears 自己进入这个市场。想法其实很简单：把明天的 web 技术带到今天的浏览器里。这些特定的功能大部分都来自新的 HTML5 规范，但是标准制定小组已经在上面花费了好几年。不想再等这个小组完成规范，Google 自己通过件对浏览器进行扩展，实现了这些功能并且达到了那个小组能达到的最高水平。他们宁愿在短期内抛弃标准（原话是“以后再考虑实现”）也要把他们的 web 程序带到能够对抗 Flash 和 Silverlight 的下一代标准。

Gears 有一个 30 人左右的小组开发，这个小组是 Google 内部开源小组的一部分。这个小组由 Vic Gundotra 带领，再一次讽刺的转变过程中，他由微软的传教士成为 Google 的高级开发者。这个一小组开发者着手进行开发，并且保持 Google 对 Javascript 和开放浏览器虚拟机的兴趣。理论上，他们看起来很可能被大组织或者微软和 Adobe 正在投入各自平台的预算所超过。为了改变这个状况，他们把 Gears 从 Google 中分离出来（字面上也是——现在这个项目名称就只是“Gears”）并且在开源协议下发布源代码。

第一个发行版将只关注于 HTML5 里面提议的新功能中他们认为最重要的功能：基于客户端的结构化数据和对象存储。由于选择了首先实现客户端存储，所以下一年里 Gears 会被构架成一个离线应用程序解决方案，由于其他的竞争者好像都没有注意到这个这么巨大目标，所以如果他们不是有意而为之，那么肯定会发展的很好。Google 本来有可能开发他们自己的浏览器，某些博客里的推测和谣言也都指出了这一点，但是浏览器市场竞争激烈，却平淡乏味，而且通常会失败。另外，即使他们开发了自己的新浏览器，他们还要驱使用户接受这个新浏览器，在决定性的市场聚集起来之前只能等待，就是这样，市场上还会有 70% 或者 80% 甚至 90% 的人不使用 Google 的浏览器，却想使用 Google 的程序。

这种情况下，可选的捷径就是跳过浏览器直接在上面增加一层——Google 自己的 web 层。所有常用浏览器都提供了让开发者扩展功能的机制，这样一来，Google 要做的就是对每个浏览器开发对应的插件。这能让新的 web API 能够适应所有的桌面而不需要用户去适应，最重要的，这比起进入浏览器市场来说见效快而且痛苦少。现在可以让浏览器来做所有无聊的事情：渲染 HTML、显示界面、用户选项等等，与此同时 Google 却在改变现状，埋头向前冲。

现在 Gears 支持大量完整的新功能，有一些新功能是和微软、Adobe 他们的下一代 web API 相同的，而其他的则是 Google 自己创造出来的。现在函数调用已经对开发者开放了，包括后台处理（不会再有沙漏出现）、客户端图像处理、位置感知、更好的文件上传功能，还有浏览器内本地数据库。

要让新 API 和开发平台的应用被采用需要两方面的支持，一方面是用户的支持，因为这需要用户安装新的插件；另一方面是开发者的支持，使用 Gears 不会让开发变得更容易，这是因为这和开发其他的使用基于浏览器的 Javascript 的程序没有区别，Gears 只是给开发者提供了一系列更多的可以在浏览器内实现的功能而已。Javascript 和 web 开发者不需要学习任何新知识，用户也要做的也只是安装一个插件（与浏览器绑定的交易肯定会发生，所以这一步都可以忽略了）。Flash 花了 5 到 6 年才足够普及，能够让开发者有信心专注于使用 Flash 开发，不过有了 Google 的支持，Gears 可能只需要用一半甚至更小的时间就能做到。

在这场竞赛中，Google 没有任何损失反而赢得盆满钵丰，Google 一下子就启动了这个新 web API 的基于标准且开源的替代方案。与其他的竞争对手不一样，Google 没有兴趣控制这个平台或者直接用来盈利。相反他们却在试图维持现状：大部分程序使用浏览器里的 Javascript 开发，如果有更多需求那就使用 Flash 或者类似的技术。

上一次平台大战结束了很久了，但是每次你都能看到类似的技术经验：大公司失败，小公司成功。给这个平衡增加点开源的砝码，结果还是没有一个单独的公司能够占优势。有这么多大公司的加入，而且如此的利益攸关，我们肯定要亲眼见证一场漫长的持久战。只有时间能够告诉我们 Google 的做法能不能带领 web 向前发展。

本文是 Nik Cubrilovic 写的下一代 web 系列中的一篇，在这阅读其他同系列文章。

本地存储相关的 API 作为最新的 HTML5 规范草案的一部分，我们在上个星期看到一些浏览器和插件已经开始采纳这些 API。虽然 Gears、Opera 还有 Webkit 都已经实现了结构化存储部分的 API，但是 HTML5 规范里其他的部分当前还都没有怎么实现，而且前途不明。HTML5 尽了最大的努力来让所有的浏览器都统一在一个单一且标准化的标记语言和一系列 API 下——但是 微软、Adobe 和 其他的领先者们都有了自己的下一代 web 技术，那么我们还能看到真正的 HTML5 标准吗？

历史的教训

在适用范围和成果方面，HTML5的成果与历史上早期的 HTML 3.0 规范 有所相似。返回到 1995 年 4 月，开始起草 HTML 3.0 规范，其目的是向后兼容 HTML 2.0 并且添加新的特性（例如表格）。当时 W3C 刚刚成立，这个新工作组要完成的第一批规范之一就是 HTML 3.0 规范。 在那个时候，浏览器大战即将爆发，当时 Navigator 才发布了五个月，却占有了 80% 的市场份额。微软却才注意到这点，然后仓促的开始开发 Internet Explorer 1.0，并在几个月后发布。

在 1995 年，不同的浏览器支持不同系列的标记——一直到现在还是这样。随着 Navigator 1.1 新版本的发布，网景突飞猛进，而且还实现了表格、浮动图片和其他的导航元素（例如点击过的链接）。IE 1 是一个完全改造过的浏览器，因为它采用了最大化渲染的方法，就是说，如果 IE 无法确定用户对 HTML 所期望的表现，就尽量猜测并且显示猜测结果。 这导致了很多类似标签不匹配的问题（例如 <b><p>Header</b></p>）出现，因为 IE 能够自动纠错，所以这些问题又导致开发者变得懒惰。

随着 Internet Explorer 的市场占有率持续上升，以及网景和微软各自浏览器的每一次发布和更新，两个浏览器的距离越来越大，市场也随之分成了两个坚固的阵营。以前以 RFC 形式出现的，现在叫做 HTML 的规范，本来的目的是重新统一浏览器，并且让浏览器已经支持的新功能规范化。但是在规范制定者中经常会弥漫着剑拔弩张的气氛，争论究竟哪个浏览器——Navigator 还是 Explorer——对新功能实现的更好。例如，Navigator 和 Explorer 对图片映射图的实现方式就很不一样，而且还互不兼容。微软要为制造那些混乱的 HTML 标签所负责，例如使用 <top> 和 <bottom> 标签来定义页面中不变的部分（拜网景所赐，这些标签后来演变成了很不友好的框架标签）。

问题不在于新功能无序的开发，而是两个竞争激烈的浏览器都在实现各自版本的 web，以保卫自己的市场份额并且或者更多的控制权。最后，网景和微软都放弃实现正统的 HTML 3.0 规范，例如网景声明：

网景承诺继续支持 HTML 3.0。出于这样的原因，我们走在了前面，采纳了一些更加成熟的方案，我们希望这些方案能够被认可。我们坚信网景 Navigator 2.0 比其他的任何一个商用客户端对 HTML 3.0 规范支持的更好。

此外，我们在网景 Navigator 中增加了一些现在还未被 HTML 3.0 规范包含的新功能。我们认为这些新功能应该被加进去，作为标准流程的一部分，我们正在提议标准加入这些新功能

而微软被落在支持 HTML 小组成员的后面紧紧追赶：

网景非常享受他在浏览器市场上的事实垄断地位（据估算约有 90%），这让网景可以通过引入非官方的，或者所谓的“扩展”标签来加固它的垄断地位。结果导致 web 上充斥着只能在 Navigator 里面正确的浏览的垃圾页面。等到其他的浏览器追上来的时候，网景完成了更多这样的扩展。

但是持续了不长时间，微软就厌倦了这种玩法。新的发行版甚至都不提及 HTML 而是改为讨论构建在微软技术上的 web：

微软 Internet Explorer 3.0 是第一个集成了ActiveXTM 技术的英特网客户端，这项技术能让开发者能够在英特网上创建具有很高交互性的程序和内容。这些技术能够让万维网站变得丰富、互动，就像动作游戏、多媒体百科全书或者生产力应用程序那样。有史以来，网站第一次不再被技术所限制，而仅仅受限于作者想象力。

浏览器大战爆发了快一年的时候，战争从对 HTML 标签支持的斗争升级到了开发富客户端程序的格式和语言之争。在 1996 年 8 月，随着 Internet Explorer 3.0 的发布，Javascript（网景私有的客户端脚本语言）和 ActiveX（微软私有的对象容器）之间的斗争一触即发。

这个故事剩下的部分就是微软在哪里取得胜利的，以及更重要的，微软是怎么赢的，然后浏览器大战已经成为了历史。由于 Web 分裂的很严重，其影响持续了十几年，浪费了开发者很多的时间去开发跨浏览器技巧和各种库。尽管微软得到了浏览器市场的控制权，而且一直不遗余力的推销它私有的用于构建 web 程序的多层技术，但是不知怎么的，最简单的 HTML、Javascript 和 CSS 却赢得了广泛的支持，而且 Web 2.0 也没有构建在 ActiveX 的基础上。

十年后

随着网景逐渐消失并且被 Firefox 替代，今天的 web 大战不仅仅发生在浏览器之间，而且还发生在新 web 平台和技术之间。据估计，Internet Explorer 的市场占有率已经降到了 78%（2004 年达到了最高的 95% 市场占有率），同时 Firefox 占有 16%，Safari、Opera 和其他的浏览器共同占有剩下的 6%。1999 年 HTML 4.01 规范发布，因为大部分浏览器都内置了对该规范的支持使得该规范成为 ISO 标准。HTML 4.01 一直是支持的最广泛、最好的 HTML 标准，不过现在的问题已经转移到了其他的 web 技术上，尤其是 CSS 和 DOM 访问。

在现在被称之为 Web 2.0 领域内，上千个富 web 程序都是使用 HTML、CSS 和 XML 开发的——通常称之为 AJAX（很讽刺的是，AJAX中的 A 和 X 部分最开始时是 Internet Explorer 的私有插件，以 xmlhttprequest 的形式出现的）。虽然 AJAX 程序很快就达到了当前技术所能实现的极限，但是这些程序缩短了桌面程序和 web 程序之间的距离。很多厂商都发布了他们支持的 web 客户端平台作为浏览器之上的一层，例如 Adobe 开发的 Flash、微软开发的 Silverlight 等，这给开发者展示了一个丰富多彩的，开发类桌面化的 web 程序的开发环境。这些新的平台通过在现在的浏览器基础上增加插件来生效，由于这些商业解决方案的发布，导致当下没有一个合适的、开源的、基于开放标准的、超过 AJAX 的替代品出现。

在 W3，一组浏览器开发者受挫于 HTML5 缓慢的进展，他们独立出去成立了 WHATWG 小组以促进该规范的开发。HTML5 的首要任务就是认清楚现状，那就是从最初的 HTML 规范发布以来，web已经发生了翻天覆地的变化，现在的 web 程序能够展示非常复杂的用户界面，能够利用更多的高级系统功能（以界面为例，Silverlight 使用 XAML，Flex/Flash 使用 MXML）。该标准开始成为 Web Applications 1.0，这个宽泛概念不仅包括有新的 HTML5 规范，还包括了其他相关的规范，例如 CSS2、DOM5、ECMAv4 和新的 API 调用（例如本地浏览器存储）。

WHATWG 工作组最终（4年后）又返回了 W3，微软也重新投入了力量。与此同时，开发者如果要搜索不是 AJAX 的富 web 程序平台，只会得到很少的结果，除非他们投入微软或者 Adobe 的怀抱。HTML5 规范的实现进展非常缓慢，直到 Google 意识到微软和 Adobe 正在统治 web 的威胁并且通过开发 Gears 介入才有所改观。Gears 是 Google 匆忙的在浏览器上实现 HTML5 的产物，他们使用 Gmail 和 Reader 这些自己的程序一步步的支持这些新的 API 调用

苹果是另外一家全力支持使用非 HTML5 的开放技术开发富网络程序的公司。就在几年前，访问苹果主公司主页的浏览者所看见的是充斥着 Flash 和 PDF 文件的页面。现在，苹果拥有了 Safari——他们自己的基于开放标准的浏览器，并且支持 Webkit 这个开源项目。苹果使用 AJAX 而不是 Flash 这样的私有技术重新开发了他们的网站和程序，他们通过这样的方式来支持免费且开放的技术。

我们又回到了 1996 年，只不过现在 HTML5 成了新的 HTML 3.0， 当时只有两个主要浏览器厂商，而现在有很多的团体都对决定新的 web API 和虚拟机的样子充满兴趣。在这一九十年代的事件里，开放标准赢得了最终的胜利——微软和 Adobe 意识到这点后他们都公开了一些各自平台源代码和 API 细节。

Web 历史告诉我们，在通常情况下，只会有一个胜出者，然后所有的用户都逐渐迁移到这个胜出的解决方案上，并且使之成为一个标准（回想一下很多现在的“标准”最初都是私有技术）。尽管类似 Windows 操作系统这样的标准和类似 HTML5 这样的开放标准之间的差异巨大——但是类似 Google 和苹果这样的公司要面对的最大的威胁就是历史的重演。

“下一代 web”系列中的上一篇讨论的是本地浏览器存储，点击这里阅读。

下一代的 web 已经开始上路了，就在这个星期，MySpace 集成了 Google Gears，雅虎发布了新的 BrowserPlus，Google 的浏览器版三维地球也上线了。类似 AIR、Silverlight、JavaFX、Gears、XUL、Web Applications 1.0 (DOM5, HTML5 等) 这样的技术和格式让开发者能够超过 AJAX 加速冲向下一代的，有着更好的性能、更多的功能，而且和桌面集成的更加紧密的 web 程序。

现在，因为各个公司都急于展示他们自己的下一代 web 的样子，导致开发者和用户都被前所未有的超多 web 技术所压迫；“DLL 地狱”也被“插件地域”所取代。但是在 web 上，这样过多的选择会导致用户和开发者的成本增加。第一次 web 格式大战已经过去十多年了，那个时候微软、网景、苹果、美国在线还有其他公司都在浏览器标准、脚本语言、web 服务等方面成立了不同的基金会。这次大战的影响一直持续到现在，例如 Javascript 来发展需要依赖整套的代码库来开发跨浏览器代码，CSS 开发者需要一系列 hack 才能让他们的站点能够在不同的浏览器中看起来都一样。

现在新一代的富 web 程序技术还都在开发阶段，所以还有机会采用基于标准的态度，来避免重蹈覆辙。幸亏有了过去十多年的教训，现在连微软这样的公司都在以更加开放的姿态来接纳开放标准、数据迁移还有跨平台支持。不管是用户还是开发者，对开放标准的广泛支持都能简化他们用到的技术，但是明显的，并不是所有当前发布的新技术都能支持开放标准。

在 Techcrunch 这一系列帖子里，我们来看看这些组成新一代 web 的各种元素，并且评估可用的选项，当前支持的标准以及对标准的采用情况。由于 MySpace 刚刚宣布他们在程序里面使用了 Google Gears，那么我们的第一篇就来评估基于浏览器的本地缓存。

基于浏览器的本地存储

随着基于 web 的应用程序逐渐流行，就有了希望能够离线运行这些程序的需求。第一个不需要任何插件或者独立程序的解决方案是那些靠缓存 HTTP 头信息来在浏览器缓存里存储信息的方法。类似 Dojo 对离线 web 应用的支持这样的 Javascript 库使用的就是这样的原理，但是这样的程序应用范围非常狭窄，因为没有一个好的办法在浏览器里存储结构化的数据。（Dojo 现在引用了很多包括 Gears 在内的其他的存储引擎——提示：Dylan）

在 2007 年 5 月，Google 发布了Google Gears，一个浏览器插件，它允许 web 程序把数据同步到本地存储器，然后可以离线使用这些 web 程序。在 Gears 发布会上，Google Reader 被重写以支持 Gears，Gears 的突出的重点是离线访问应用程序。但是不被所知的是，Gears 不仅仅能够用来离线访问，它还提供这三大功能：

• 缓存资源（HTML 页面、图片等）
• 在数据库中存储结构化数据
• 异步后台工作线程

在这部分我们关注的是本地对象和结构化数据存储。Gears 通过 Javascript API 来提供相应的功能，这些 API 可以被任何 web 程序访问到。Sqlite，一个轻量级 RDBMS，提供了结构化存储的支持。由于使用了本地数据库，开发者不仅可以执行查询、插入新纪录这样的操作，还能执行更复杂的 SQL 操作，例如连接多表查询等。尽管你可以有多个使用 Gears 的程序，但是每个程序都要运行在一个基于域名的安全模型的沙盒环境里（类似 cookie 和 AJAX 请求）。虽然 Sqlite 已经嵌入 Firefox 2.0 以后的版本，但是它的 API 只能够被 Firefox 核心组件或者附加模块访问到。Gears 插件弥补了这个缺陷，让客户端脚本环境也能够访问到这些 API。

在 Gears 发布前，万维网超文本应用程序技术工作组 (WHATWG) 已经着手制定 Web 程序规范 1.0 草案，这个草案把结构化数据存储包括到了 HTML5 里。该草案当前版本包含了对访问数据库对象和查询本地数据存储的定义。实现的细节虽然交给了各个公司去完成，不过规范里面已经详细说明了 API 的细节。Firefox 将会在 3.0 版里实现一部分和 WHATW 规范一样的存储 API，不过这个版本现在只有预览版可用。WHATWG 规范里的关键部分有：

• 程序缓存 ——在本地浏览器缓存里存储对象（包含校验）。
• navigator.onLine——测试浏览器是否在线（使用缓存，如果需要则加上本地数据存储）。
• 存储界面和事件——用来通过 sessionStorage DOM 属性存储“名称／值”对。
• 数据库界面——用来连接本地数据库。支持 SQL语法（或者其子集，取决于使用的服务器）、版本控制和错误回调事件。
• 线程和回调——这样多个请求就能够异步发送给本地数据存储。

调用本地存储、缓存和离线访问相对来说很简单。程序首先检查是否支持相应的函数，然后通过在后台同步用户数据进程来设置本地缓存。当一个线程在运行的时候，不管是上传还是下载，你可以查询进程状态并且给用户一个反馈（例如一个进度条）。一旦数据本地化，由于是在本地机器上运行数据库，开发者就能大幅度的提高查询性能。当下很多 web 程序仅仅把浏览器用作展示层，例如，电子表格软件就是做 =1+1 这样简单的计算也要进行一次到服务器再返回的请求。通过使用本地数据存储和客户端代码，开发者可以减少到处理和存储到客户端的负荷，同时还能提供给用户更加平滑、类似桌面程序的体验。

当前和将来的支持情况

现在的问题是大部分 WHATW 规范都是在 Gears 发布后才写的，导致 Gears 使用的数据库和本地服务器对象和 WHATW 规范不兼容——至少当下是这样的。好消息是 Google 已经发现了这个问题，完全支持 WHATWG HTML5 规范中的存储部分，因此，对于那些运行在安装了 Gears 的 Firefox 3 中的程序的开发者来说，他们可以选择使用 Firefox 原生的还是 Google 实现的存储。Google 还说他们很可能会提供额外的功能，以激励开发者关注那些 Gears 超越 HTML5 的实现（例如桌面快捷方式等）。

其他的本地数据存储可选方案，例如 Flash 本地存储，和 WHATW 规范完全不兼容。WebKit 的开发人员很快声明他们也开始实现 HTML5 规范中的存储部分。而且在每晚构建的代码里已经可用了，因此很快我们就能看到 Konquror 和 Safari 对本地存储的支持。Opera 也声明了类似的计划，而且当然他实现了 HTML5 和 web 表单后他们会领先于所有人。雅虎 BrowserPlus 昨天才发布，所以现在还不明确他们他们的本地存储支持和工作组发布的规范是否兼容。

本地存储是新一代的 web API 中重要的新功能，开发者不仅有跨浏览器的一致支持，还可以选择使用 Google Gears（已经可用）还是 Yahoo! BrowserPlus（取决于它如果工作）。还有一个浏览器厂商我们到现在一直没有谈到，那就是微软。微软发布了 IE8 的一个早期预览版，而且预告了大量的新特性，其中很多都是基于开放标准的，例如更好的 CSS 和 Javascript 支持（内涵一个更加标准化的对象模型）。最大问题是，IE8 在本地存储方面会不会遵循和其他浏览器厂商一致规范。IE 开发小组声称 IE8 将会支持 DOM 存储，但是这只是全部本次存储规范的一部分（即前面提到的 Storage 对象）。

当前和将来的支持情况

注：一旦得知 BrowserPlus 的细节，我们就会完成这个表格。Google 保证 Gears 能够适应标准。IE8 宣称不完全的支持。WebKit 的每晚构建里面大部分功能都可用了。Flash 和 Silverlight 支持某种形式的本次存储但是不是 HTML5 标准 API。

一个类似本地浏览器存储这样的新技术被如此广泛的提倡和支持，而且大部分都是基于一个规范，实在是一件罕见的事情。虽然微软还没有宣称完全支持，但是毫无疑问的，他们会朝向正确的方向。Google Gears 和 Firefox 3 的实现都遵循着 HTML5 的工作组规范也是很鼓舞人心的。虽然短时间内这些新版本的浏览器不可能被广泛的使用，但是 Google Gears 已经可用了，而且，因为所有的厂商都瞄准了同样的 API，开发者现在就可以安心的锁定 Gears 存储 API 然后开工——者在不久以前还是不可能的事情。

有了本地浏览器存储和缓存，开放标准到现在为止都是赢家。而其他的替代解决方案很可能会半途而废，或者改变以实现同样的 API。