JCloud software design

JCloud is written in C++ under Linux POSIX, which is often compatible with other POSIX based OS'.  Some core code may also include code for other OS' (Windows, Mac).
The primary target is x64, but all code should also work with ARM64.
Current standard is C++17. This means code must be able to be compile under this standard, not that new functionality in this standard is used.
External libraries may also be written in C.
Historically, there was often a mix of C and C++ code in projects. Include-files therefore typically had file extension .h regardless of C or C++.

The build environment use GNU makefiles. The makefiles are written for threaded compilation (make -j).

An application is usually either a service, a client/tool or a web page.
We do not develop X / GUI applications, only web.


A service often accept requests from users. It may also initiate requests. The file structure is typically

A service should support shutting down gracefully with TERM signal and then return an exit code of EXIT_SUCCESS.
Any other exit code shall be classified as a failure. Service failures will cause JService to alert the monitoring system and restart the service.

Service bootstrap configuration

Most services use a database to retrieve/store data, which may also include some service configuration.
In order to connect to this database and get other data, the service loads a bootstrap configuration file first using JModule_Config.
These files are plaintext files with "key value"-lines.

A service usually holds an object containing bootstrap configuration and database pools. It is often called Context or RootContext.

Existing J Modules

The following is a list of some of the different core ABI modules that exists

Module name
DNS client queries
Supports async, sync, DNS and DNS-TLS

Use it for services only
Supports mySQL, postgreSQL and MSSQL
Bootstrap config

File storage
TLS certificates

ERP/CRM system frequently used
Mail sending
Client SMTP connector
Store and retrieve time based statistics

TCP based services

Some services listen on TCP/TLS and use a proprietary protocol, often based on text lines. It could also be that this protocol is based on a RFC.
Unless it is a RFC we these days prefer using jhttp/REST unless it is not viable for the service.
There is existing j-code for dealing with TCP/TLS based services, both asynchronous and synchronous.

HTTPS/REST based services

There is a project called jhttp which includes the entire http-stack as a stand-alone application called httpd. It is modular and can load engines which will deal with the actual http-requests.
Several such engines exist and is used depending on the project. There is also an engine for general purpose webserver with php support called webcdn used by webhosting customers.
It is a good idea to use jhttp in new projects for REST-support.
It is also possible to compile jhttp directly into an application, skipping the separate httpd application.

Client tools

Sometimes a service comes with client tools for doing tasks or other type of jobs. Perhaps a cleanup task
The structure of such applications are limited and could contain only the main file.

Web pages

Web pages are based on jhttp and an engine which again typically loads a dynamic HTTP::Page so-object when requested by a client.
These pages come in different sizes and shapes, rest-based and not.