Data Model

The Data Model allows components and scripts to use and monitor information provided by different services, and to set properties and invoke actions provided by services, through a standardized interface. This design document takes a closer look at the Data Model, and the standard directory structure it will have in Dime.

Top level structure

The following is a list of the top level folders in the Data Model.

System data, perhaps OS, etc.

Client data, such as name, version number (as major, medium, and minor integers), and so on.

Not sure about this one. Could perhaps be used to store user name and contact information, but that might go into preferences too.

Default user interface, various settings, like default GUI theme, some service specific general settings, and so on.

List of game servers, and information about them.

Accounts on different servers (multiple accounts on same server possible too).

Avatars/characters that an account owns on a server.

Currently active interfaces for controlling the Avatar(s) and any vehicle, in game device, or other things with control interfaces that they control/use.

Information about the part of a world that some group of sensors in a control interface can see and sense. Contains a list of the entities, an accessor that allows fast access to geometry data, streams of incoming sound events, current weather data, and so on.

Contains addresses to one or more metaservers used to find other servers.

Contains list of media servers (or sources?), and what media packages they contain.

MediaObjects / MediaCache / MediaPackages / MediaProxy
Contains list of current media packages with information about them. The connection between the media cache/library/archive/store and the game views happens directly on a code level to optimize data transfer and method calls.

GUI themes downloaded by this user. Uses media from the media archive/cache/proxy.

User interfaces / Layouts
Specifications for how to arrange a number of component instances and scripts to provide an user interface for viewing/manipulating some aspect of the game on a part of the screen, and specifying how the whole screen space should be composed of various layouts and components.

Specifications / Program Interfaces / API's
List of specifications for various functionality, dialogs / queries sent by the server, and so on. Each one has a sub folder containing all registered implementations of it. One of them is always used.

Contains a folder for each custom plugin script. The plugins can be used to provide component model features for other scripts from a well defined place.



Running Components
TODO: better name?

Running scripts
TODO: better name?


The root of the tree of visible component tytpes.


Input bindings?

Scheduled taksk?