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.
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:
|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|
|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 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:
|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.
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:
|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:
|headerLogger||Log the headers of all incoming requests|
|applicationLog||The log output of SwifterLog|
The domains use the following data structures:
|domain||Domain||Setup of the domain itself||Core.Domain.swift|
|domainTelemetry||DomainTelemetry||Telemetry for the domain (communication based|