一种在未来互联网中的面向用户的云操作系统体系

本文描述了一个欲将整个网络当做计算机使用，可以极大增强云计算应用能力和提高用户体验的一个类操作系统体系结构。望有识之士能做下去。

 

 

价值

1）用户的痛苦在哪里？

对于终端用户，他们的痛苦在于使用Web应用不方便，可以使用的Web应用种类有限。

对于开发者，他们痛苦就是在现有条件环境下开发不出能满足终端用户的软件来。

2）解决方案是什么？

为Web应用提供一个共同的协调处理消息的机制

3）用户能得到什么益处?  用户的付出/成本是什么？

用户从此可以方便地如同使用桌面软件般丰富和便捷的Web应用，而开发者在有了这套机制的环境下使得Web应用可以做的事情大大扩展，减少一些用户易用性的忧虑。   终端用户可以免费地无需安装地使用此机制，为了更方便也可以加装些平台相关插件，开发者如欲使用更强大的API提供更好的服务，则需针对这样的机制开发一些代码（也可以完全不变而享受一些简单的功能：如被调用的机制），

某些涉及资源的API可能是收费的，另外在App market上发布的收费应用，作为交易平台也须支付部分费用。

4）目前有什么竞争对手？

目前并没有这样的系统，但是怀疑Google内部有这样的计划，其最近推出的App Market和其API已经显现了它这方面的打算，但是就现在看，它还没有瞄准为现有应用服务，并且API都只是与Google自身相关的，不能称之为影响所有应用的云操作系统。HTML5标准也计划了Web Application的通讯机制，但是没有消息中心。

但是这个系统的打算明显的是其战略目标。

 

 

背景

云计算在云端的技术发展得十分迅速，谁也不可否认其计算能力强大，终端无关，数据共享等优势。

云计算希望个人终端仅仅承担接入设备，而浏览器是目前最好的接入设备标志性配备。因此Web应用是大多数云计算应用的展现方式。

 

然而，Web方式展现的应用目前的主要缺点在于对终端用户的易用性。

桌面应用与桌面操作系统的交互能力，在目前来说是大量Web应用无法与之匹及的。 比如，你打开一个什么什么文档，一般桌面系统自会调用相应的软件打开来；操作系统触发的事件，应用软件可以监听；一个软件还能侦听其它软件所触发的系统事件。

以独立网页展现的众多Web应用则缺乏这个能力，使得不少Web应用使用不便以及能力受到很大的限制。

 

它们之间很大的一个区别在于Web应用没有一个共同的协调处理消息的机制。不认为云计算能完全替代桌面应用，但是可以具备足够的能力完成大多数需求，可现在的能力是不足的，仍需加强。

 

 

         早就有人预料到了这一点，因此他们推出新的互联网规范（HTML5）来使Web应用具备更强大的能力。可是在主流浏览器支持之前，单独的应用是没有资本让用户装个插件什么的来支持这些。而且即使有了通信规范，一个集中式的管理消息的“操作系统”也是必要的。

 

 

效果

先描述一下在完备的云操作系统体系下的互联网使用情景（当然很多特殊应用是不可摒弃桌面系统的）：

所有的资源存储于云上，使用于云上，数据直接在互联网服务器之间传输（或是以流的方式在客户端过一下）：你可以在互联网上做的各种操作，可以依据Web应用对云操作系统的接口利用程度实现相应粒度的活动记录和状态保存。这样，你可以在不同的地方工作，耗时长久的操作可能只要发出指令就可以关机，切换环境后再继续。

Web应用可以发出或者接受云操作系统事件：在众多用户的帮助下，接受事件Web应用可以利用现有Http的 GET或POST 的REST API（这是绝大多数web应用获取输入的方式）无需改动，在用户的授意下主动接受云操作系统的事件（采取App市场机制靠群体智能匹配提示）。最简单的例子就是资源的打开，在启动云操作系统后，在用户单击某资源链接后，会自动导向相应的Web应用直接打开资源（在用户选择好之后）。

事件的类型是灵活的，多可能适应的。

Web应用同样可以主动监听指定类型的事件，或者发送自己的事件以提供扩展机制。这样，新的Web应用就可以互相监听事件而有更广阔的发展前景。

 

结构

云操作系统体系主要包含如下几个方面：

1.       以HTTP协议为向用户通信的基础的应用

现在已经充满网络

2.       基于通用账号的云操作系统服务

存储接口

资源搜集管理

消息-处理器映射及集中收集与转发

云操作系统级活动记录

验证转发（对于使用通用账号的应用，就可以不流经客户端访问资源，否则若用户不愿意发送Cookie等信息，资源流需过客户端）

转发路由，存储缓存等后台优化措施

3.       终端的Loader

要启动云操作系统，准备好事件监听转发，活动记录等环境。这部分的实现首先要实现一个过渡时期的产品，使得现代浏览器可以完成未来标准将正式支持的特性，这样可以使得应用先发展起来，将来的标准的推广才能顺利。

此结构现有几种实现方式（可以都实现）：

a.       纯Js实现，可以辅以浏览器插件（没有不影响工作，有了更方便，最好是使GreaseMonkey这类插件能成为标配）：

优点：跨终端能力强； 缺点：Js冲突可能导致不正常工作

b.       浏览器插件（利用标准通信）

优点：体验好，可靠； 缺点：跨终端能力差

 

4.       事件发布和主动接受机制的协议

定制页面上的调用规范，供新的应用主动发布自定义事件或监听某些事件。使用现在正制订中的标准。

5.       云软件市场

用户用以指定自己使用偏好的依据。也可在其上发展商业模式

 

 

现有进展

原型项目Cloud Resource Explorer实现了访问资源这个消息的转发，可以直接在互联网上转移数据，打开资源。还有互联网资源的收集与管理。涉及上述2，3，5部分。第一部分现已不少，而HTML5草案也将第4部分做得差不多了。

 

考虑到资金问题，若是做一个小的试探性可用项目，可用先做原型系统去除存储能力后的效果，不过仍是要少许存储空间。  

可是我个人的时间，资金都不足，无法独自继续下去。