Overview of the the Atlas toolkit


You will find here some technical details about the Atlas toolkit.


We currently focusing on delivering a functional toolkit, by following the release often, release early philosophy. So, it's important for the Atlas toolkit to be easy to install, but also, for us, easy to publish.

Some properties of the Atlas toolkit make this difficult:

  • it provides bindings for several languages (Java, PHP...),
  • it relies on (C++ written) native code ,
  • it is available for different OSes (GNU/Linux, macOS, Windows...),
  • it is available for different architectures (IA-32, AMD64, ARM...).

Until we find a better solution, the Atlas toolkit currently relies on Node.js, and its dedicated package manager (NPM), for both the installation and publication, for following reasons:

  • the desktop interface relies on Electron, which, in turn, relies on Node.js,
  • the web interface relies on a Node.js based web server,
  • there are some Node.js modules which facilitates the handling of C++ native code.

This implies that, whichever binding you use, to retrieve the Atlas toolkit, you currently need to install Node.js.

We are aware that this is not a satisfying solution for the those who want to use the Atlas toolkit, but not the Node.js binding of it. In this case, they should not have to install Node.js to obtain the Atlas toolkit, even when using the Electron based desktop interface.

We are looking for a way to achieve this, and any suggestion about this issue is very welcome on the dedicated forum, by opening a discussion or participating in a related one.


When launching an Atlas toolkit based application, there are two applications which are launched.

The first one handles the user interfaces, currently either the desktop one or the web one. The desktop one is an Electron application, the web one a Node.js application.

The second one is either a pure Java, Node.js, or PHP application, depending on the selected Atlas toolkit binding you are using. This one acts as a daemon, to which the above application connects. This is currently the easiest way for us to establish the communication between both applications, as it works with all bindings.

Proceeding this way also allows to dispatch the software between different computers, for load balancing purpose. And, for the coming mobile interface, as it could be difficult for some languages to run natively on mobile devices, one part can be run on the mobile device, giving the application a native feeling, and the other part, which handles the user interactions, on a remote server.

If you wish, this issue can also be discussed on the dedicated forum.

As the web interface and the desktop interface (through Electron) are both currently based on a Node.js for all the bindings (this will change in the future), they use a Node.js wrapper which source code can be found here: http://github.com/epeios-q37/njsq.

The web server source code can be found here: http://github.com/epeios-q37/xdhwebq-node.

The desktop source code can be find here: http://github.com/epeios-q37/xdhelcq.

For links to the source code of the components used by each bindings, see the page dedicated to the binding you are interested in.


Take also a look to the insights of the various bindings: