Platform Extensibility Working Group

From Rex community wiki

Making RealXtend a Platform for Custom Virtual World Applications

(a new writeup as a proper article at: Platform_Extensibility_Working_Group/Entity_Component_Article

Summary

In project RealXtend we are developing a virtual worlds platform that should support somewhat free programming of functionality or arbitrary applications. In this position paper we outline current work being done in the Opensim core and in the Naali viewer development to reach this goal. The basic idea is to allow arbitrary data to be stored both on the server and in the clients utilizing an Entity-Component model, have the networking synchronize that data (automatically), and support running custom code both on the server and in the client to implement the custom functionality and user interfaces.

Background

RealXtend started in autumn 2007 as a project to implement a virtual worlds platform which overcomes certain limitations of other systems such as Second Life(tm). The first prototype was quickly made a a fork of both slviewer and opensim, published in February 2008, including new features like the use of the Ogre renderer with 3d mesh support, webview textures ('html on a prim'), integrated VNC etc. Later the server side modifications were refactored to be both changes in the Opensim internals, and an additional OpenSim module called ModRex which implements the features.

After the first prototype, we came to see what that building new features on the slviewer codebase was problematic for several reasons: Reportedly it is not a modular base but quite entangled, so customizing and extending is difficult. The OpenSim contributions policy prevents working with the slviewer code, which is very cumbersome because adding new features easily requires touching both the server and viewer code. Also the Ogre integration in the first ReXViewer prototype uses OpenGL context sharing to have also the Linden code drawing the UI, which does not work and all graphics card drivers.

Therefore in late 2008 we decided so write a new viewer from scratch, using existing open source libraries like the Ogre renderer and GUI libraries. The idea was to first implement the basic functionalities against the existing protocol and server, but only the basic features like getting the scene and movement, and not all Second Life (tm) features like parcels and proprietary messaging groups etc. Instead the plan is to use existing standards like XMPP for messaging, and have an extensible architecture for functionality. After initial planning the programming started in the beginning of March 2009, and the first usable version of the Naali viewer was released in February 2010 (Naali 0.1).

Current State and On-Going Work on Extensibility

The basic idea in the new RealXtend work is to implement a base platform on top of which arbitrary applications could be implemented. We plan to get there by having both the viewer and the server implement a similar Entity-Component model, which can handle and store arbitrary data, and having a networking protocol that can synchronize that data. In addition to that, we need to support running arbitrary application code in modules / plugins that implement the functionality that uses the data.

On the viewer side, in Naali, we started this by building the application as a module framework where parts can be easily enabled and disabled, and new modules can be written by third party authors. For the initial design, refer to http://wiki.realxtend.org/index.php/NG_Design_Document/Viewer_Architecture/Framework . Basics of that are implemented in Naali already and used to build the features we have in separate modules, but the reality of the code is still quite far from an ideal solution. In general all ReX development is about balancing long term framework elegancy ideas, and short term needs to implement features -- as some companies are already using Naali to deliver applications to customers and there are more plans in near future (during spring 2010).

In the OpenSim server, we are sponsoring a long-standing refactor of the internal scene code. Adam Frisby will lead that work, starting now in March 2010, and realXtend and other OpenSim developers can and probably will participate in it. For the proposal, see A. Frisby's email from December 2009 with the plan attached - http://lists.berlios.de/pipermail/opensim-dev/2009-December/008098.html . This should result in OpenSim implementing an Entity-Component data model, similar to Naali, which can be used by extension modules to store arbitrary data.

We do not currently support running arbitrary untrusted code from services. Right now, the modular architecture and extensibility is utilized by companies using RealXtend technology by writing application specific additions to it as trusted code. This can be done either in C++ or Python in the Naali viewer, and in C# or (Iron)Python in Opensim+ModRex server. We use the SLUDP GenericMessage message type for additional client-server communications, both for old ReX core features and applications specific custom messages (see http://wiki.realxtend.org/index.php/RexProtocol).

The plan is to use Javascript for untrusted code in the Naali viewer, similarily to how it is used to write custom UI and login in Web browsers, http://wiki.realxtend.org/index.php/Interpreted_Languages_Working_Group/Javascript_support . We may add basic support for Javascript/Qtscript written custom UIs during spring 2010.

Later steps: switching the protocol?

An on-going investigation in RealXtend development is the possibility of using another protocol, instead of the SLUDP inherited from Second Life(tm) and Opensim LLClientView. A need there is to support more efficient networking where e.g. custom movement messages could benefit from coalescing etc. Candidates here include the combination of ENet and Google Protocol buffers, MXP, and the Kristalli protocol developed in one of the RealXtend developer companies for other projects. For a comparison of the candidates see http://www.bubblecloud.org/wiki/-/wiki/Main/Comparison and related discussion on http://groups.google.com/group/kyoryoku/browse_thread/thread/8bf0f57e888480f5

The eventual goal is that an extension could just define a data type, and either the serialization/deserialization mechanism for it or utilize an autoserialization mechanism, and have the data synchronized cross the participants so that custom code can process it either both on the server and clients, or on either end as needed. We are not targetting a possible switch of protocols right now, but possibly later e.g. in autumn 2010 if it proves useful.

Remarks

RealXtend is an open source project, not affiliated with any single company, that develops a base platform that should be useful for many kinds of applications. This is similar to the Opensim development, with the difference that in ReX the focus has been now on the client side. It is currently a combination of ambitious goals, working basics, nice enough architecture, and terrible work-in-progress hacks.

We welcome any feedback and are interested in new use cases and requirements, and especially of people willing to scratch their own itches by contributing patches. We can give commit access to contributors like normally in open source projects.