关于在线储存应用的一些随想

最近由于我的一些需求，我尝试了不少的在线储存服务，也因此有了一些关于在线储存的想法。简单地说我认为目前的在线储存服务大都被当作一个简单的文件寄存箱，而大部分的这类应用自身的定位（网络硬盘）也确实如此，这让我感到十分惋惜，个人认为这一应用的可扩展性非常之高，因此本文记录的更多的是我的一些随想。

不过更让我郁闷的是，即便是最基本的文件储存应用都没有多少在线储存服务能够满足我的要求。我对文件储存服务的评价很简单，下载/上传速度、稳定性、保存期限、空间（包括单个文件大小限制）、分享的便利性和效率以及文件管理的效果。

基本上第一个条件就将大部分的国外在线储存服务淘汰了，而硕果仅存的几个国外在线储存服务又因为剩下的各个条件而一个接一个地被淘汰了。其中我比较满意的是SkyDrive，其让我感到略显不足之处是空间和分享便利性和效率这两个条件，其中后者是造成我放弃其的关键原因。虽然我非常崇尚简洁，但简洁的基础应该是高效，SkyDrive上传文件只能通过上传页面而且不具备上传进度查阅、断点续传和多任务管理功能，这使其无法胜任大规模的文件寄存需求。

而国内的在线储存服务的选择就更少了，不过所幸几乎是唯一的选择中存在一款虽然尚有欠缺，但基本能满足我的需求的服务--纳米盘（仅就我的需求而言，无意为其做宣传）。因为我寄存的文件需要长期储存，因此无法提供永久储存服务的都被我排除在外了。纳米盘提供的单个账户1G的永久储存空间和单个文件300MB的限制基本能满足我的这一需求，稳定性就其到目前为止的表现而言尚属可以接受（尽管有少数文件会出现无法正常连接的情况）。而让我最终选择纳米盘的原因正是我刚才提到的放弃SkyDrive的原因，纳米盘提供了一个能够让我高效管理多账户上传的客户端。尽管我对纳米推广其客户端的方式颇为不满（对大文件强制要求使用客户端下载），但其客户端基本符合我的简洁定义，功能也能够满足我的基本需求。此外纳米盘对于已经上传过的文件能够自动识别避免重复上传，这一点对于节省时间和其磁盘空间占用非常有效。这就是我最终选择纳米盘的原因。

让我感到非常不解的是我认为我的这些要求都是非常合理而不苛刻的要求，甚至可以说是最基本的要求，但国内能够勉强满足的却只有纳米盘（或者还有我不知道的，欢迎推荐）。而国外的服务由于地理位置的因素基本无法与之竞争，这简直像是在拱手让出一个可以垄断这一需求的机会……但单纯的文件储存在我看来价值已经越来越少了，分享文件的需求早已被P2P应用占据了不少的市场，而储存文件的需求由于硬盘价格的降低也越来越低，因此在线储存应用应该寻求新的需求和价值。

其中的一个方向目前已经有此类应用的服务商在尝试了，简单地说就是在文件储存的基础上融入在线使用文件的应用，也就是加入Web Apps模块。比如Box.net对于一些特定的文件（如：办公文档）能够提供在线的浏览工具而不需要下载到本地再利用本地的桌面客户端浏览。这不仅是起到了提高效率的作用，而且也是象征着一种未来的趋势。我一直坚信在线应用最终可以完全取代桌面应用，而如果能够将网站下载到桌面这一过程舍弃，那必将使用户对于在线文件储存服务的依赖度和归属感大大增加，也因为满足了更多用户的需求而使受众面大大增加。但和大多数的Web Apps的开发一样，其仍然受到许多限制，主要的阻碍就是提供服务的成本以及实现的技术难度的增加。

另一个方向我似乎仍没有见到哪个实例，简单地说就是以用户上传的文件作为入口，融入SNS元素，延伸出类社区应用。举个例子就是通过融入SNS元素来加强用户的分享行为。要实现这一点首先需要对用户上传的文件能够做到有效的甄别和分类，但依靠目前的技术要做到这一点非常困难，因此更多的应该依靠对用户的引导，使用户能够主动地完成这一过程。但似乎目前大多数的服务都没有进行这一引导，以纳米盘为例，其虽然具有Tag系统，但在客户端上传时其甚至没有提供给用户填写Tag的模块，只能在完成上传后在后台编辑，试问这样的Tag系统和形同虚设有什么区别。当然，要让用户主动完成这一过程仅仅靠引导是不够的，需要提供给用户足够的动机。

一个不难实现但我似乎没有看到有哪个服务去做的方法就是提供一个文件聚合系统。这个系统的基本功能应该包括公共文件搜索功能和相关文件显示功能，在用户认可了这一系统后引导用户提供更多的信息，理由是能够使这一系统更加准确和增加新的社会化功能模块。至于这一模块我认为除了能够实现前面提到的两个基本功能的准确度提升外，还应能够利用用户的共享文件历史来提供一个推荐系统。这一推荐系统不是用于推荐其它用户共享的其可能感兴趣的文件，而是向其介绍和其兴趣类似的用户，关注这些用户就可以得到其分享文件的活动提示。在此基础上可考虑通过与其他外部应用的合作来强化这种基于文件分享为入口的社会化关系，最终形成一个SNS社区，目的同样是增强用户对网站的黏度，引导新的需求使应用价值提高。

最后想发一下牢骚就是现在基本所有的在线储存应用（或者说目前阶段应该叫网络硬盘更加合适）都不提供公共文件搜索系统，而且对文件分享页面的设计非常不利于搜索引擎索引，空置着许多资源而不利用，对于用户和服务提供商都是一大遗憾。

浅谈Web Apps的开发要素

正如我多次提及的，我认为Web Apps的最大的优势和特点就是便携性。这一特点是所有Web Apps天生就具有的。不过我认为目前的Web Apps对这一特点的拓展不够广泛。目前大多数Web Apps都是采用Google Docs的模式，将待编辑的文件默认储存在服务器中以实现这一便携性的特点。然而这种做法毕竟不是长久之计。我不是指硬盘空间不够，硬盘是现在最不值钱的东西了，而是指由此带来的对服务器压力的增加。这种做法只能适应于目前使用Web Apps的人数还比较少，因此同时使用的用户并不多，对服务器的压力还不算大。

试想一下，当Web Apps的普及程度达到今日Microsoft Office的普及程度时，如果Google Docs取得了今日Microsoft Office般的垄断地位时，即使是拥有全世界最多服务器的Google我相信也未必能处理得了那么大的对服务器的压力，一旦服务器出现问题那对用户的影响绝对是极大的，而由此引起的对Google的打击也必定是毁灭性的。

因此我认为Web Apps或许可以考虑采用B/S架构与P2P架构相结合的方案来缓解服务器的压力。我认为Ｂ/Ｓ架构和Ｐ２Ｐ架构都各有优缺点，不能完全偏向某个架构。当同一时间使用人数少时，由于网络状况等各种原因，如果只采用Ｐ２Ｐ架构很可能给使用者的使用效率造成很大的影响，这时采用Ｂ/Ｓ架构既可以保证使用者的使用效果又不会给服务器带来太大的压力。而当同一时间使用人数多时，采用Ｐ２Ｐ架构可以有效减少服务器的压力，而且由于使用人数多，应该可以保证大部分使用者都能有一个较好的使用效果，并且可通过对使用者下载速度的检测对部分网络状况不佳的使用者自动切换为Ｂ/Ｓ架构。

并且借助Ｐ２Ｐ架构还可以继续拓展为一种分布式的储存方案，利用每个使用者作为一个储存节点，每个文件都有多个备份，这样也可以有效保证数据的安全性。不过要这个想法似乎就要在保护用户隐私上下很大工夫了，而且必须让用户自己决定是否作为一个向其它用户共享的储存节点。

而Web Apps的第二个开发要素就是用户使用的便捷性和使用速度。目前我在测试众多Web 2.0服务时都经常要面临一种很不愉快的体验，大部分Web 2.0服务都要求我注册一个帐户才允许我使用，而没有提供一个类似来宾帐户之类的试用帐户。

我认为这一点对于新推出的Web 2.0网站而言是很不利的。目前Web 2.0服务针对的用户大多对网络隐私极其看重，因此注册帐户意味着要向一个不知道是否可以信任的陌生网站提供隐私数据。我就经常因为顾虑这一点而放弃了测试许多我应用需求并不强烈的陌生Web 2.0服务。然而那些允许我进行匿名测试的Web 2.0服务我通常都很愿意花一点时间来仔细体验其提供的服务，这就是很大的差距。虽然我在测试过后未必会成为其用户，但至少我进行了测试，这是由测试者转变为使用者的必经过程。而许多Web 2.0服务因为不允许用户匿名测试而将许多用户拒之门外，这对其自身和用户而言无疑都是一种损失。

我上文提及我之所以不愿意注册帐户除了对泄漏隐私的顾虑外还有一个原因是注册帐户的过程十分繁琐。而Web Apps的使用者恰恰是追求使用简洁和速度的。我第一次使用Web Apps就是因为我要对某幅图片进行一点简单的处理，而我又不想为此去下载和安装一个可能只需要临时使用一次的庞大臃肿的工具。因此我就在Google中尝试搜索寻找是否有这样的在线应用，结果我很快找到了一个在线的编辑图像服务并迅速完成了我所需要的编辑工作。从此我就开始使用Web Apps来代替一些软件的应用。

因此某些Web Apps服务（比如Microsoft的Web Apps服务）喜欢用ActiveX控件来开发，我认为这是一种极其愚蠢的行为。先不说ActiveX控件只能用于IE平台，而且ActiveX控件的安装过程耗费的时间不亚于注册一个帐户所需的时间。而且经常会在此过程中由于各种原因造成安装失败（比如我从来没有成功安装过Microsoft的Web Apps......）。因此用以开发Web Apps的最佳平台我认为目前还是JavaScript语言，JavaScript不仅支持各个浏览器平台，而且无需安装即可使用。

由这个例子我们又可以发现Web Apps的一个特点。Web Apps通常在功能上都不如对应的计算机软件。这有一部分因素是由于技术所决定的，而另一部分因素则是由Web Apps的特点所决定的。然而为何Web Apps却能从这些软件用户中抢夺走了一些用户呢？除了我上文提及的便携性外还有一个原因，这个原因我在浅谈应用服务整合一文中已经简单地介绍过。并不是所有的用户都需要一个软件的全部功能，很多时候我只需要用到一个庞大的软件的一个小功能，这时候这个软件对我资源和磁盘空间的占用都是极大的浪费，因此我为了避免这种浪费就转而使用已经能够满足我的应用需求以及对资源和磁盘空间占用极少的Web Apps。

然而虽然Web Apps有资源和磁盘空间占用少的优势，但随着硬盘和内存容量的不断增加，事实上大部分用户对资源和磁盘空间占用相比起以前已不太在意。因此Web Apps要想将这部分用户巩固就必须做到达到和计算机软件相同的使用效率或更高的使用效率。由于服务器和客户端的网络带宽都有限，因此Web Apps必须牺牲一部分Web Apps所针对的用户不常用的占用带宽大的功能，以此来换取用户较好的使用效率及体验效果。而不是一味地追求功能的完善，Web Apps在现阶段功能永远不可能超过同类的计算机软件，而Web Apps又必须受到网络带宽的限制，如果不加节制地增加功能只会造成用户体验效果下降而丧失用户。因此Web Apps必须有一个正确的用户定位才能进一步地进行开发创新。

Web Apps的第三个开发要素就是开放API接口。提供足够的资料供第三方开发相应的支持应用。其实这一点不只是Web Apps需要注意的，开发计算机软件同样如此。我们可以发现，目前十分受用户欢迎的软件（如：foobar2000、Firefox等）大多都是开放API接口并且有十分多的插件拓展支持的软件。可以说正是有了这些插件和拓展才使这些软件成为一个成功的软件。而这些软件之所以能获得如此多的第三方开发应用支持，正是由于其开放的API接口使第三方开发者能很轻松地开发各种插件和拓展来加强和完善这一软件。

Web Apps上的典型示例莫过于Google Maps和Twitter了。相信现在大家都对各种Google Maps Mashup很熟悉了，而之所以会出现这么多的Google Maps Mashup全部得得益于Google开放了Google Maps的API接口。利用Google Maps API才能开发出众多有趣和实用的第三方Google Maps Mashup应用。事实上在这个过程中Google Maps也因为这些Google Maps Mashup而大大提高了知名度，对Google Maps本身的推广也是十分有利的，因此开发API接口可谓是服务提供商和第三方开发商的双赢的选择。

最后一个开发要素就是要注意Web Apps的离线化应用，但由于我之前以专门写过一篇文章来阐述这一开发要素，这里就不再赘述。愿意详细了解探讨的读者请参看从Google Gears看Web Apps的离线化应用。

版权声明：本作品作者为IwfWcf，首发于IwfWcf's Blog，转载请遵循知识共享署名-非商业性使用-相同方式共享 3.0 许可协议并以超链接形式注明出处。

从Google Gears看Web Apps的离线化应用

我一直以来都认为Web Apps的离线化应用不只是单纯的支持在完全离线的环境下能进行工作，那样不应称为Web Apps的离线化应用，而只是Web Apps的离线桌面客户端罢了。这种离线客户端和普通的桌面软件没什么区别，丝毫不能体现出Web Apps的优势所在。

我认为Web Apps最大的特点和优势就是与互联网的结合，在理想化的状态下甚至可以脱离桌面进行使用。因此Web Apps的离线化应用不应将离线与在线完全分离。我认为最理想化的状态恰恰是能在离线与在线之间无缝切换，借此甚至能完美解决Web Apps对网络带宽的需求的瓶颈这一Web Apps的劣势。

当然以上所述都是一种极度理想化的状态，因此目前在Web Apps离线化应用尚在探索过程中时不能要求能达到这种水平。可以说Google Gears相比其它Web Apps的离线化应用平台而言，很成功的一点就是其将Web Apps 离线化后的应用在浏览器中进行，而且访问Web Apps的网址不需要改变。这一点能很好地体现了我所提及的Web Apps离线化应用中很关键的一点：在离线与在线之间无缝切换。相比起其它将Web Apps离线化应用理解为一个可以在线更新数据的桌面客户端的厂商而言，Google对Web Apps离线化应用的理解无疑是处在一个不同的高度的。

不过Google Gears在发布后所受到的广泛赞誉又有些言过其实了。实际上Google Gears也仍有大量的不足。这些不足共同体现在了多个已经以Google Gears为离线化应用平台的Web Apps中。为了行文简洁，我就以Google Reader的离线化应用举例说明。

虽然Google对于Web Apps的离线化应用的全局理解是十分深刻的，但应用到了具体的服务上的实现效果则并没有想象中的优越。Google Reader实现离线化应用需要下载完2000个item的数据，我认为这一点十分不合理。首先下载item的数量不宜过多，Google Reader这一服务的实效性十分高，下载过程中数据很可能已经更新了，虽然可通过重新切换到在线状态查阅更新，这并不符合Web Apps离线化应用中离线与在线之间的无缝切换的要求。而且下载item不能通过设置过滤条件进行有效筛选以及不能选择特定的item永久保存。

上述提及的都只是一些细节上的不足，我相信随着离线化应用的深入都将得到解决。而Google Reader离线化应用最大的败笔我认为是没有与Google的搜索进行整合。我认为Web Apps离线化应用还有一个很大的作用就是对信息进行更高效的筛选处理。特别是Google Reader这一服务就更能体现这一应用需求。然而Google却连最基本的搜索应用都没有提供。

我为Google设想的理想化的Web Apps离线化应用的搜索平台是Google Desktop。利用Google Desktop全面整合处理Google的各种Web Apps离线化后的数据，以此来使Google桌面平台的软件与网络平台的服务之间的整合更加密切，这也十分符合Google的整合产品策略。借此可以使用户对Google服务的黏度进一步提高以及大幅度增强Google Desktop的推广。

不过十分欣喜的一点是诸如Apollo等Web Apps离线化应用平台均表示将兼容Google Gears。能在开展Web Apps离线化之初就统一标准是一件好事，这样可以在日后免除许多麻烦，对开发者和用户而言均是好事。我期待着基于更多基于Google Gears平台的Web Apps的离线化应用的出现以及离线化应用的进一步完善。我可以预见未来那个Web Apps全面取代桌面客户端的时代的到来已经是不可逆转的潮流了。

版权声明：本作品作者为IwfWcf，首发于IwfWcf's Blog，转载请遵循知识共享署名-非商业性使用-相同方式共享 3.0 许可协议并以超链接形式注明出处。