俺的垃圾箱

     摘要: 愚作之 SNDA-RPC 是基于JSON-RPC[1] 的扩展和修改，其目标是继续保持它的简单调用，修正其不足，以及扩展它对RESTful[2]的支持。SNDA-RPC 是运行在 HTTP 协议[3]上无状态的，轻量级远程调用协议。 SNDA-RPC描述了两类资源，Service API资源和Data API资源： * Service API资源，即通常所说的远程方法API资源，只能以HTTP GET或POST的方式被调用。其Service API的数据格式使用的是JSON[4] * Data API资源，即数据资源，可以被CRUD(Create, Read, Update, Delete)操作的资源（注，可能许多数据资源都是只读性质），Data API的数据格式使用的JSON[4], Atom[5],RSS[6]。 草拟阶段，您的建议对我很重要.  阅读全文

REST的使用，多从资源角度考虑设计，而我却以为不竟然，我以为可以同时从资源和RPC的角度考虑设计。
首先要明确的是RESTful是一种面向Sevrice和资源的架构类型，而不是标准，与此相对，它使用了如下的标准：
* HTTP
* URI
* XML/HTML/JSON/GIF/etc（Resource Representations）

注：这里的“资源”可以理解为，1、真实的资源（可以CRUD）；2、看作是Service API返回的结果（只能R）。
 
REST架构的具有如下特性：
统一接口：所有的资源通过统一的接口访问（HTTP GET, POST, PUT, DELETE)）
统一命名：REST系统中的资源(API)必须统一命名和规划，REST系统由使用URI命名的资源组成。REST最大的优势是提出了一个可以对资源和RPC统一命名的URI标准。这难能可贵。
交互形式: 主要以拉(pull)为基础的交互形式，通过长连接实现push。
可以缓冲：提升网络效能，可以将资源（响应）分为可缓存的和不可缓存的。
资源呈现：资源呈现（Resource Representation）允许有不同的表现的形式（text,xml,json,bin,gif,...）, 同一RESTful API可以取得不同表现形式的Resource。
分层组件：可以在客户和资源之间插入不同的中间组件来提升性能和安全等，如，代理服务，缓存服务，网关服务等。
无状态：本次连接和下一次到服务器的连接之间没有状态。这在在服务之间需要状态的时候是弊端。如果服务内的状态可以用长连接解决（如聊天服务）。


RESTful使用http方法（GET, PUT, DELETE, POST）来调用API或管理资源.
从RPC API的角度来看，这些方法的使用目标如下：

Http方法     使用目标
GET          可以缓冲的 resources
GET, PUT     可以缓冲和修改的 resources
GET, PUT, DELETE 可以缓冲，修改和删除的 resources
POST         不能缓冲的 resources

OpenSocial, FaceBook, NetVibes 都致力于社区平台的研究发展。

其中OpenSocial和NetVibes侧重于整合并和提供第三方Gadget到社区平台的标准。而FaceBook则从自身平台的需要，为了吸引更多的开发者更容易开发FaceBook App，提供了平台API，并开放了部分平台源码。

FaceBook是从社区平台自身数据->API开始制定社区平台的标准的。而OpenSocial则是从社区平台的功能互联互通开始着手制定的。

与OpenSocial类似的则是Netvibes，Netvibes也是以Widget(Gadget)入手，提供了Universal Widget API，其侧重点为开发用于个性网站（个人门户或个人桌面）的通用的Widget。与iGoogle的Widget相比，其窗体的表现更为美观，功能更多，License为可用于商业化的GNU LGPL. 其Widget的XML格式也和OpenSocial的Gadget类似（不知道是谁抄袭谁的）。
他们都提供客户端Gadget API，RESTful API，以及Gadget容器。

shindig是google的一个opensocial容器的参考实现:http://incubator.apache.org/shindig/，实现了java和Php两种语言的容器服务器。php的较为简单，用svn checkout出来，即可用（我已经安装测试过了），java的必须使用Maven工具编译。

Netvibes Platform(LGPL Open Source):
  优势：开放（承诺源代码全部开放，兼容大部分Widget:iGoogle, Opera, Apple Dashboard, Window Vista, Window Live；但是目前的开放进度缓慢），美观，功能，速度
  弱势：公司没有足够的影响力去推动UWA作为标准

Exposition Widget Server 是Netvibes 提供的容器参考实现（PHP），我的测试是极为简陋，只是简单渲染了Widget的内容，根本没有窗体外壳，别谈什么功能了。

与FaceBook的比较（Facebook Open Platform(f8)）
FaceBook License： Common Public Attribution License (CPAL) and Mozilla Public License (MPL)..

API： With the API, you can add social context to your application by utilizing profile, friend, Page, group, photo, and event data.
FBML： Facebook Markup Language (FBML) enables you to build full Facebook Platform applications that deeply integrate into a user's Facebook experience. You can hook into several Facebook integration points, including the profile, profile actions, Facebook canvas, News Feed and Mini-Feed.
FBML is an evolved subset of HTML with some elements removed, and others which have been added that are specific to Facebook. You set the FBML for a profile box by calling profile.setFBML through the API. The FBML is cached on Facebook's server until profile.setFBML is called again through a canvas page.
FQL：Facebook Query Language, or FQL, allows you to use a SQL-style interface to more easily query the same Facebook social data that you can access through other Facebook API methods (assuming your application has access!).
FBJS is Facebook's solution for developers who want to use JavaScript in their Facebook applications. We built FBJS to empower developers with all the functionality they need, and to protect our users' privacy at the same time.

与此还开放了Thrift——跨语言的Service库；MemcacheD——分布式内存对象缓存。

Viewer, Agent, Region
Viewer 是通过控制一个角色与虚拟世界交互的客户端，角色Agent 是持久存在的，控制该角色玩家离线也可能与之交互。Region也是持久存在的，是虚拟世界的土地。
众多的角色存在于土地上。

基本流程：
  1. Viewer 向 Agent Domain发出认证请求控制一个Agent
  2. Viewer 指导 Agent Domain 将角色放在一个区域
  3. Agent Domain 联系 Region Domain 请求获得该区域服务， 并协商该角色的放置位置
  4. 区域服务授权访问给Agent Domain，并一部分授权访问给Viewer.
  这时，交互开始：
    Viewer 访问 Regions Resource 移动 avatar
    区域通知 Viewer Resource 更新区域中对象的状态
    Viewer 访问其它 Agent 沟通交流。

SL社区数据的可移植性
http://dataportability.org/
提供策略和一组技术标准（已存在）使得在社区（social networks）玩家能共享他们的数据到其它服务上，控制他们的去向，重新组织等等。
另一方面，SLGAWG期望SL能被internet共同使用，并最终成为领导业界的基于开放协议的开发虚拟世界基础架构。

虚拟世界不仅仅包括3D数据，而且还包括众多的社区数据，如个人信息，好友信息，群组信息，他们之间通常存在可以彼此发送信息的机制。
因此我们只需要非常简单使用已有的一系列的开放标准，让虚拟世界融入社区之中。目前计划使用的开放标准如下：
  × 数字认证标准： OpenId/YADIS
  × 个人信息(Profile): hCard/FOAF
  × 好友列表： XFN/FOAF

SL开源的服务器端核心库(python > 2.3)

SL开源的目的是希望自身从3D虚拟世界网络娱乐，上升至服务平台，乃至成为业界的标准。SL认为，3D虚拟世界将组成了未来的网络架构，必须开放形成标准才能走在前面，更快的发展。自07年9月开始，由Zero Linden领头的Architecture Working Group 开始致力于规范和改善现有SL的通讯协议，同时包括服务器端和服务器与客户端之间的通信。主要目的是为了能在未来的SL Grid架构上，不仅能跑现有的SL，而且其他公司或私人搭建的虚拟世界也能跑。解决这些虚拟世界之间的相互链接，互联互通的问题。

目前开放的有Eventlet和mulib：

Eventlet: 使用非阻塞网络IO编写的高度伸缩性能的网络库，用来实现一个骨干Http服务。
  Require：
        greenlet(http://cheeseshop.python.org/pypi/greenlet)
        pyOpenSSL(http://pyopenssl.sourceforge.net/) 需要SSL的时候
  下载： http://svn.secondlife.com/trac/eventlet/changeset/8/branches/beta-1?old_path=%2F&format=zip

mulib: 是基于REST的Web服务架构，底层使用eventlet.httpd作为网络通讯库。
  Require：
         eventlet,
         simplejson(http://cheeseshop.python.org/pypi/simplejson)
  文件说明：
    * auth.py : 实现 HTTP 基本认证.
    * cgiadapter.py : cgi适配器，使得与MU应用作为cgi交互成为可能.
    * console.py : 多用户信息浏览终端，用于维护和监视服务状态。
    * eventrouter.py : Eventrouter 是浏览/服务器模式下的消息传递框架. It's used to build many of the neat little web apps included in mulib.
    * htmlexception.py : 格式化异常信息为html格式
    * logconsole.py : Eventrouter 日志终端
    * mu.py : 给出了来自mulib大多数最重要的API函数, 如：mu.Resource
    * nodes.py : 实现基于http的出版/订阅机制.
    * shaped.py : 用于描述python objects的meta信息的系统。, using python objects. E.g. a list of ints [1, 2, 3] has the shape [int]. Also at the proof-of-concept stage.
    * resources.py : mu.Resource的有用的子类.
    * shellconsole.py : 在浏览器中与python shell交互, 使用eventrouter实现
    * sourceconsole.py : Interactive source code browser for eventrouter. It's been a long time since anyone has looked at this code, it probably needs some freshening up.
    * stacked.py : 基于URL的递归遍历Python 数据结构。The various consume methods match up path segments from a url with a hierarchical data structure. The produce methods convert data for transport over the wire. The names of these methods are somewhat confusing, we could use some better ones.
    * testconsole.py : Unit test running and reporting application built with eventrouter.
    * tests.py : A place to keep test utilities. Lightly used, but it will become more useful as test coverage grows.
    * virtual.py : 虚拟主机(Host)实现(i.e. dispatching based on the Host header).
    * caps.py:  capability 服务，客户(Viewer)请求capability服务获取对特定功能的访问。
      URL Spaces(capability 提供的三个服务):
        /cap/grant
          调用该服务将记住Private URL，并返回一个Public URL（Capability 服务的代理地址）
        /cap/multigrant
        /cap/revoke
          取消某个PublicURL对应。
        /cap/UUID 为调用capability 代理服务。
      例子：看看登录的时候如何获得 AgentHost会话的(Seed) Capability 服务URL，首先客户进行登录（login server），login Server 在 AgentHost上启动一个新的会话，AgentHost想授权客户能访问该服务，于是AgentHost将该会话(seed)服务的私有URL传递给capability 服务，执行 /cap/grant ，返回该seed服务的PublicURL，然后AgentHost将该PublicURL地址发给登录服务，登录服务在作为登录响应一起返回给客户。
      好了，下次你就可以和AgentHost会话服务交谈了——通过Capability 代理服务。连接该PublicURL，实际上是连接上Capability 代理服务，Capability 代理服务然后在查找public对应的 privateURL，并将动作转发给该privateURL。 AgentHost Seed服务将检查你访问授权，通过之后才返回给你新的PublicURL去访问新的服务。
      利弊分析：
        利： 客户端不需要每次服务都去认证，不用保持用户会话信息，服务端也不用去管理实现用户权限验证。这由AgentHost中的 Seed capability 服务来解决，问题是它是如何知道哪个服务该授权给用户的？
        Seed Cap 需要知道每一个服务模块，以及如何访问他们的URL。目前SL的用户权限比较简单，只要为“居民”和“神”两类，
          其它某些服务需要处理他们自己处理认证并以某种方式连上会话服务用以获得权限。这个时候Cap可以很容易的把他们插接在一起。
        弊：网络流量增加。你不能直接知道你想使用的服务URL地址，你必须去Seed Cap服务询问获得该服务的URL。这意味着一次服务，需要两次Http连接请求（当然服务的CapURL地址可以在客户端缓冲）。
            seed cap服务必须知道每一个服务，以及如何去调用它。这不算什么大问题，从另一个角度看，也许还是优势——客户端用不着知道所有的服务。

SL目前采用的是 http REST轻量级SOA＋专用协议(区域主机)，数据序列化格式目前使用的是XML，将来会增加Binary和Json格式。

SL的设计目标：
  虚拟世界区域可伸缩性能
    * 6千万地图区域 (或更多)

  居民数量伸缩性：
    * 20亿用户

  同时在线用户数量伸缩性：
    * 5千万 - 1亿的同时在线用户(无论来自哪个平台)

SL的核心架构是由区域(Region地图)世界域Domain和角色（Agent）世界域Domain构成。

一、区域(Region地图)Domain

区域(Region地图)又分为区域服务，区域主机(Host)和区域数据仓库(Stores)等服务。
区域服务是用Python编写的无状态的HTTP/REST Service,区域主机则是专用协议高效的在某个区域的消息状态服务，处理该区域内的一切交互，而区域数据仓库则是数据层服务。
区域服务用于处理和区域相关的无状态信息：
    *  Avatar 位置
          o avatar 在缩略图上的位置 (绿色的小点)
          o 来自其它角色的请求
                + 交谈
                + God / Support level
    * 对象信息
          o 元数据 (名称 / 说明 / 待售)
                + 搜索
          o 任务物品
          o 地理位置
                + 打造地图图像
          o 区域统计 (FPS/Frame Times/etc)
    * 土地信息
          o 名称 / 说明
          o 当能搜索才公开

区域主机用于处理该区域的一切交互行为，也就是在SL中常提到的simulators。
    * 物理引擎
    * 脚本执行
    * 本地 avatar/脚本化聊天

区域主机的划分是一个有意思的课题：
  区域的适度大小划分
  区域的角色（Agent）数
    物理运算的能力
    脚本执行能力
可惜这部分并没有开源。

区域数据仓库

区域数据仓库存放了某个区域的数据：
    *  对象信息
          o 地理位置
          o 形状/贴图
          o 链接/组关系
          o 物品
          o 元数据
                + 名称 / 描述
                + 许可
                + 版本信息
    * 区域信息
          o 许可
          o 贴图
          o Logs
          o Metrics / Stats
    * Parcels(一小块土地)
          o 元数据
                + 名称 / 描述
                + 许可
                + 元数据
          o 搜索设置

角色（Agents）

角色(Agents)也同样分为角色服务，角色主机（Host）以及角色数据仓库等服务。
角色服务用于处理角色相关的无状态信息，角色主机（Host）服务实际上角色会话服务，保持的是和角色相关的状态的信息，同样角色数据仓库为其数据层。

     摘要: 云式计算既描述的是计算平台也描述的是应用平台,从应用平台角度来说是云式计算基于分布式处理、网格处理和并行处理的商业化实施，它信奉的观点是SaaS(软件即服务)，强调处理无所不在的分布性和社会性。而从计算平台的角度来说，云计算的目标是解决超大规模数据中心的分布式计算的问题。  阅读全文

     摘要: 传统Web开发，一般都是以客户端作为主动的，客户端发请求，然后接收响应，然后再发请求...，整个流程都是以客户端为推动源。这样的一个结果就是，一般的web框架都是把他们的控制器分成一个个的方法调用，客户端的请求就对应到这些方法调用当中。而Web Continuation Server 通过引入Continuation机制将逻辑反转了过来，并以此实现了对于page flow的完整描述。  阅读全文

     摘要: 所谓Continuation就是保存接下来要做的事情的内容(the rest of the computation)。举个简单例子，我在写文档，突然接到电话要外出，这时我存档，存档的数据就是Continuation(继续即将的写作)，然后等会儿回来，调入存档，继续写作。Continuation这个概念就协程来说就是协程保护的现场。而对于函数来说就是保存函数调用现场——Stack Frame值和寄存器，以供以后调用继续从Continuation处执行。换一个角度看，它也可以看作是非结构化Goto语句的函数表达。当我们执行 Yield从协程返回的时候，需要保存的就是Continuation了。  阅读全文

     摘要: 基于 WEB 的实时事件通知方式大致有五种方案：HTTP拉取方式(pull)，HTTP流，Long Polling，Flash XMLSocket方式，Java Applet。

首先说下Comet这个词，Comet 这个词是最早由Alex Russell（Dojo Toolkit 的项目 Lead）提出的，称基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推(Push)”技术为“Comet”。
  阅读全文