Sequences
- User invokes ./bin/omega-server
- Base initialization and config (code)
- Create RJR nodes for configured transports (code)
- Adds subsystems to RJR dispatcher: (code)
- rjr.add_module invokes the initialization method for each module (rjr code) (omega code)
- Each module's init method performs tasks required to bring that module up, including:
- Starting registry subsystems (code)
- Running rjr methods in a custom 'environment' (code) 1. Environments are modules added to the scope that RJR method handlers run in 2. Thus the methods defined in that module (such as 'registry') will be available to all rjr method handlers which that environment is associated with 3. RJR also adds various other variables which we can leverage, see the RJR README for more info
- Adds other modules in the subsystem to the dispatcher (code) 1. Those initialization methods will be called at this point, registering all the subsystem's json-rpc methods with the dispatcher (code)
- Finally the module's init creates users / adds permissions / registers callbacks / does other things that the subsystem requires to fully operate (code)
- After all modules are initialized this way, bin/omega-server wraps up by setting up some signals (to gracefully kill the process and take/restore backups) and blocks (code) until SIGTERM is captured
- Eventmachine captures an event via TCP, HTTP, AMQP, a local Unix Socket, or any other transport (tcp node)
- It hands it off to RJR, if it's not a JSON-RPC request it is discarded (code)
- Node creates request/notification, hands off to dispatcher (code)
- Dispatcher sets up environment for request (code)
- Dispatcher invokes request handler(s) (dispatcher) (instance_exec method handler)
- Using motel::get_location as an example, the registered method handler is invoked with the json-rpc args (converted into Ruby objects) (registration) (handler)
- The method handler looks up the location specified by the args (lookup) (lookup filters server helper method)
- If the user specified 'with_id' as a param, a single location will be returned, else and array of them (code)
- Locations the user does not have access to are filtered out (code) (unless with_id is specified in which case an error is raised / returned through the json-rpc response (code)
- The locations are returned (code)
- RJR dispatcher takes the return value or error and creates a JSON-RPC result (code)
- The result is returned to the user via the transport it was invoked over (code) (tcp code)
And that's it! (well unless the client connection is kept around and then the server / client can send requests & notifications to each other at will!)
Each page's template includes the js module for that page defined in site/source/javascripts/pages/<page.js>
The following illustrates the startup sequence which the main index page goes through when the user navigates to the site:
In addition to this, the Omega JS client runs through various sequences to handle/manage sessions and Omega entitys on various events in the UI:
Before any cosmos or manu data is loaded, the unique universe id (autogenerated on each server startup by default) is retrieved and checked against the cached copy.
If different all cached entities are invalidated so that the fresh universe can be loaded
On anonymous logins the default system set is loaded. This is currently retrieved from the server by retrieving the 'systems_with_most' 'entities' stat and loading those systems from there
A non-anon session may be established by:
- Specifying autologin credentials in config.js
- The js client detecting a previously established session via cookes
- The user clicks login in the nav, supplies valid credentials, and then clicks the login button
If the first case fails (autologin) the JS client will error out. It is assumed the autologin credentials statically set in config.js are valid.
The second case could fail if the user navigates to the site after previously logging in and waiting the session duration. If so the JS client will automatically detect the invalid session and log the anon user in
If the third case fails the user will simply be notified and reprompted for credentials
If the non-anon session establishment succeeds, the user's entities are loaded from the server and processed
- The entities are added to the local registry
- The entities are added to the navigation
- The entity systems are loaded
- The JS client begins tracking the entities
User owned entities are tracked through-out the entire duration of the client session regardless of the scene being viewed or other operations
Whenever a system is loaded, whether via the default systems in the anon case or the systems the user entities are in in the non-anon case, the JS client runs through the following sequence
- The system is added to the local registry
- The system is added to the navigation
- The system's galaxy is loaded
- References to the system & children and by the system & children to other entites are resolved from the local registry
Systems are periodically refreshed throughout the course of operations (for example whenever the scene is set to a system), whenever this is done the above sequence is run through to sanitized the latest data set
Whenever a system galaxy is loaded the JS client runs through the following sequence
- The galaxy is added to the local registry
- The galaxy is added to the navigation
- The galaxy's interconnections are loaded
- References to the galaxy & children and by the galaxy & children to other entites are resolved from the local registry
Galaxies are periodically refreshed throughout the course of operations (for example whenever the scene is set to a galaxy), whenever this is done the above sequence is run through to sanitized the latest data set
A scene change may be trigged when
- A galaxy or system is click in the navigation
- A child system is clicked when viewing a galaxy
- An entity is clicked in the navigation in which case the scene is set to its system and the camera is focused on the entity
On a scene change the entities in the entities in the system are retrieved / resynched locally as the JS client subscribes to various system-wide events such as jumps in/out.
Various high level flare & effects are added to the scena include a skybox, stardust, and galaxy particles, and all the visual components instantiated in the children directly under the root entity are added to the 3D scene.
The user may interact with the entities in various context-dependent ways.