[Uni-verse] Update of WP 6.2 (Alternative Server implementation)

[Emil Brink]

[...]
> Disk based/using server
> -------------------
> It will be possible to save the current state of the server onto the disk
> and reload it (in projects). This will give the end user the possibility to
> make backups and to store or load different server or scene setups.
> Futhermore it´s possible to transport the current state of a server to
> another server – even if this is done offline. More on project handling: see
> below.

This sounds interesting. How have you envisioned doing this? Just saving 
out the entire contents of the server to a single file? In what format, 
in that case? Or do you intend to do some more advanced handling, for 
instance to easily cope with servers holding more data than the machine 
has RAM?

As Eskil has been saying in other messages, there already exists initial 
versions of tools to save and load Verse data in an XML-based format. 
These tools run as ordinary clients, and are not integrated with the 
server at all.

The saver, excluding the Enough dependency, is ~750 lines of C, and the 
loader (again excluding low-level utility code that I just lifted from 
Purple, i.e. it cost very little time) is about twice that.

> User management and rights system
> -------------------
> In addition to the possibilities Verse itself already supports, a database
> user and rights management system will be integrated into the server. Users
> will be categorized into several user groups which have different rights in
> accessing and manipulating the data. These access rights are stored in a
> MySQL database which will be connected to the server. An additional
> PHP-based web pages system will be set up to allow manipulation and setting
> of these access rights. (However it is possible that this functionality is
> integrated into the advanced server GUI as well – see below.) Through this
> front end it will then be possible to control the user and group rights in
> the database. The server will automatically compare the logged in Verse user
> with this database and execute incoming Verse commands or reject their
> execution accordingly.

This is very interesting; I outlined such a security/rights system in 
some very early document ("D2.3 Security Implementation). Do you intend 
to define a security model based solely on the right to execute commands?

[...]
> Advanced GUI for the server (D2.3 final, page 45, optional feature 9.)
> -------------------
> Our first design of the alternative Verse server only incorporated a very
> poor user interface in a standard DOS console with text output (like the
> "original" Verse server has). As we have now more effort available we are
> now already realizing a more user friendly interface. 
> The server is running in its own window presenting several information to
> the user like for example "list of connected users (name, ip address)",
> "active nodes" or "current scene" in a tree like graph etc. 
> Furthermore the backup and load functionality will be controllable through
> this interface. We have to see if there is enough time that we integrate the
> database steering for user management into the server window as well.

Like Eskil said in his response, I find this approach a bit novel, but 
that might simply be because I'm not used to thinking of servers as 
programs having rich integrated graphical user interfaces. It might be a 
Unix thing.

Locking the server to a MySQL database seems to make it a lot harder to 
get up and running, which might be something to consider. Do you really 
envision needing so many and/or complicated tables for user information, 
that you need a "proper" database to manage it?

[...]
> "Easy of use"
> -------------------
> This will be realized through the Advanced GUI.

Did they mean the server?

[...]
> "Project handling" + "Object or project search"
> -------------------
> Together with the user and group rights management we will implement a
> database driven project management on the server. This will allow the
> separation of the Verse nodes in the server memory into different "scenes":
> These scenes can be loaded and saved. Furthermore the access rights to the
> projects of several users or groups can be set. Additionally it will be
> possible to search among saved (or loaded) projects in the server.

How do you intend to define the concept of a "project"? My guess would 
be through tags. This sounds very much like something that ought to be 
(semi-)standardized in a parallel spec to Verse itself.

Regards,

/Emil