architecture

Though it is of course possible to change every aspect, only the modules with the green color (Custom, Functions & Services) are intended to be changed by website developpers that want to augment their sites by Swift coded Functions or Services.

The orange box (OpenSSL) is the only external project that is used. All other code is developed by Balancingrock and available on github.

Sub projects

The Swiftfire software has been split in two ways: First in different sub projects that each make a compelling case for application outside the Swiftfire development. These are already mentioned on the home page, and each have their separate github repository:

Name Purpose Github Reference
Ascii Ascii character definitions link link
BRBON In-memory storage manager, fast access and load/store link link
BRUtils General purpose definitions link link
Html Makes creating HTML code easier link link
Http An API for HTTP messages link link
KeyedCache General purpose dictionary like cache link link
SecureSockets Networking utilities that implement SSL (includes COpenSSL) link link
SwifterLog General purpose logging utility link link
SwifterSockets POSIX based networking interface link link
VJson JSON interpreter/generator link link
Custom Common definitions within Swiftfire link link
Admin Administrator code within Swiftfire link link
Core Core code within Swiftfire link link
Functions Predefined functions in Swiftfire link link
Services Predefined services in Swiftfire link link

As the above packages have their own reference documentation they will not be commented on here.

Swiftfire breakdown

Swiftfire itself has been split up in several sub projects as well. This to clarify the separation between actual Swiftfire code that should be considered off-limits to non-framework developers and those parts that are (and should) be customised/created by non-framework developers.

The Swiftfire parts are:

Name Purpose Audience
Core The bulk of the Swiftfire code Framework developers
Admin Add-ons for the Server Admin pages Framework developers
Custom Additional initialisation code and dictionary key definitions All
Functions Function definitions/code to augment webpage creation All
Services Service definitions/code to augment website creation All
Swiftfire Main application code Framework developers

When in the above the talk is of non-framework developers that is of course to be taken lightly. The separation is only made to help non-framework developers rather than to prevent anybody from changing the sources of the framework.

Data structures

Swiftfire can be seen as Code + Data. The data determines how the code will perform. Understanding the purpose of each data structure is key to understanding how Swiftfire works.

There are two different kind of data structures, one for the server and one for the domains. Or rather for each domain.

The server uses the following data structures:

Name Type Purpose Defined in
serverParameters ServerParameters Low level communication between server and clients Core.Globals.swift
serverTelemetry ServerTelemetry Some global telemetry that can be used to monitor server behaviour Core.Globals.swift
serverBlacklist Blacklist A list of client IP addresses that will be ignored by the server Core.Globals.swift
services Services All the available services Core.Globals.swift
functions Functions All the available functions Core.Globals.swift
domains Domains All the domains and their aliases handled by the server Core.Globals.swift

In addition there are some logfiles that can be used to record (debug) information:

Name Purpose
headerLogger Log the headers of all incoming requests
applicationLog The log output of SwifterLog

The domains use the following data structures:

Name Type Purpose Defined in
domain Domain Setup of the domain itself Core.Domain.swift
domainTelemetry DomainTelemetry Telemetry for the domain (communication based