Introduction


On a short way we can define unga as a support system for OpenSim simulators.

As the main page of Open Simulator says:

OpenSimulator is a 3D Application Server. It can be used to create a virtual environment (or world) which can be accessed through a variety of clients, on multiple protocols.

The Application Server needs specialized services to store (or manage) users, inventories or interserver communications. By default, in Open Simulator, this is provided by ROBUST, an implementation programmed in C# for the .NET/Mono platform.

unga provides its own implementation of this specialized servers and a graphical backend, all programmed in PHP. The main advantage is clear: they can be deployed on almost any standard, an commercial, hosting service (even shared hostings) and it is as scalable as the web server is.

What unga means

It started like a joke, but soon got its full sense.

In the beginning me (Impalah Shenzhou) was developing only an UGAIM system with no name.

Talking with my partner Asha Eerie frequently about the project we discovered that pronouncing UGAIM in spanish was quite annoying, so she started to call it unga (pronounced something like oongah in english).

unga sounds to both of us like the supposedly sound of a prehistoric language of the cave men... so... that's the way the fire logo comes to the project.

Actually we think that unga is something like the center of a tribe, or the element to keep a tribe united... that is, the fire.

Why unga

Actually Open Simulator, by default, defines a series of support servers, called ROBUST, for allowing to create big simulator networks (called a grid). These servers are programmed in C# for the .NET platform.

If you need to deploy these servers you will need a .NET compatible system working on your machines. Thinking about scalability, we only have the vertical approach: if you have an overloaded server, buy more memory and cpu. None about clustering, for example. Remember, they are independent programs built from scratch usign the .NET libraries; they aren't any form of plugin for any kind of application server (Apache, IIS, WEblogic...).

Another thing to take into account is that those servers will use http/https (or TCP in general) as "external interface". And the last, their management is made using a text console or some text (ini) files.

Thinking about http servers, good performance, scalability and money saving the first thing coming to mind is Apache. And thinking about dynamic pages, PHP is the most extended language right now. Almost any web hosting company in the world offer a standard LAMP (Linux+Apache+MySql+PHP).

And we could define too a graphical backend to managing the servers, so the administration could be more fluid.

So we created unga, initially a basic replacement for the UGAIM servers, but evolves on time to a complete support system for OpenSim.

Characteristics

unga is programmed in PHP and based on the amazingly fast Code Igniter MVC framework.

unga is not only a bunch of php scripts for making support services work, is a modular CMS (Content Management System), that allows to plug-in pre-programmed modules to the system. The core unga system are a serie of utility libraries that controls, basically, the modularity of the system and the user management.

As it is deployed on a PHP server the scalability is managed by the web server. Apache, lighttpd, IIS, etc. allow to scale both vertical (on one computer adding more resources) and horizontal (server clustering).

The stability is provided too by the web server. If a script fails the server shouldn't hang up completely, only the current buggy script should stop.

For the backend has been defined a graphical API based on jquery and using ajax intensively. It provides a quick response to actions (only little parts of the page are reloaded) and, why not, a cute and comfortable way for controlling the system.

Core architecture

The architecture for the core can be seen on the image.

Unga core provides, by default, management for:

* UserManagement: auth data, user profiles, roles and permissions for roles.
* ModuleManagement: installation, uninstallation, activation, etc.
* Signals: custom functions called by core in response to events (automatic callbacks).
* UtilityLibraries: cache, uuid, graphics, etc.