In SPARC, the app menu is created from app/assets/json/global/app-menu-map.json
Each entry defines a route.
A "high level" route is then configured in app/config/baseRoutes.json that delegates a group of URLs to a controller. 
Then, a controller, in its associated .json file defines in its "routes" section the sub-route managed by the controller, 
and the method to be called inside that controller.

In SPARC, models inherit from the core and from WindozModel a mecanism that gets the URL from app/assets/json/global/services.json
That configuration file associates actions grouped in sections to API urls and http method.
Sections are identified by an URL-prefix (only used as label), and correspond to API "services".
The server-side of this API is served by the node daemon in p42api.
p42api has a folder 'api' with one file / module per API service, they are all declared in and imported by api/index.js.
Each module defines a mapping object, that contains all the complete urls served, http-method, and local handling method.

We are now focusing on P42 God Daemons (in folder p42GodDaemons).
Every daemon in there is connected to several Redis. At least one Arena redis, and one System Redis.
PUB/SUB channels are prefixed accordingly, following the configuration token "chansNamespace" 
and anything outside the configured combination Redis host & port + chansNamespace is illegal.
In the future, there might be several different Redis (in mesh) serving the same chansNamespace.

GPS Daemon is the global positionning system of the arena.
It holds the current position of every agent in the arena.
Agents change their 3D speed vector whenever they want by informing GPS (via the agentVectorChangeChannel)
A typical agent event looks like 
{ "eventType": "change", "payload": { "newVector": { "x": 5, "y": -2.34, "z": 0 } }, "sender": "agent42" }
On every speed vector change, GPS computes the 4D worldline of the agent, 
and scans all other worldlines to find those intersecting, or approaching less than a configurable distance.
Each collision/ near-miss is then registered.
As time passes, GPS fires events towards concerned agents based on this register.
On every speed vector change, this register is searched and all entries containing the agent changing its speed are deleted.
To speed-up and limit the intersection computations, we will take an approach using rectangular 4-prisms :
Each pair of wordlines to test for collision / near-miss is enclosed in a 4-prism of a certain configurable time-height (thus how far in the future we test), 
and we just test for intersecting prisms.
Only if the prisms intersect do we compute the real minimal-distance and its time, that we keep in the register.
Comparing a pair of worldlines should be a separated method and the looping through all agents in a separated method as well.
The reason for this remark is to take provision for a future where I might want to paralellize this (instead of looping through), in a GPU.



{ "eventType": "remove", "payload": { }, "sender": "agent42" }