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开源的目的是希望自身从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服务必须知道每一个服务，以及如何去调用它。这不算什么大问题，从另一个角度看，也许还是优势——客户端用不着知道所有的服务。
