The Mako Server is developed by using the Barracuda Embedded Application Server library and the Lua API provided by the Mako Server is identical to the Lua API provided by the Barracuda Application Server. The following documentation is for the features specific to the Mako Server. The source for most of these features can be found in mako.zip/.config and mako.zip/.openports.
The Mako Server creates an application table/environment per loaded application. This table is known as the "app" table and is explained in the Barracuda Embedded Web Server manual under the section Command (Request/Response) Environment.
The Mako Server looks for the file .preload when starting an application. This file is loaded and executed as a Lua script, if found. The Lua environment (_ENV) for this file is the "app" table.
The Lua code is typically not embedded in LSP pages if you write functions that are designed to be re-used by several LSP pages or if you write Lua code that is using the more advanced features of the Barracuda Application Server API's.
Functions and data in the .preload script are added to the application table. You can access this table from an LSP page as "app". For example, a function such as myfunc() can be accessed from an LSP page as app.myfunc().
The Mako Server has the concept of an application environment. The environment for an application is a location where you can keep commonly used Lua code, i.e. library functions. This environment is available to LSP pages in the application, but not to LSP pages in other applications. The application environment is referred to as the application table in our documentation. The Mako Server provides a number of environments that can be used by LSP programmers. See the Lua Overview for more information.
The server makes the following global variables accessible to the loaded applications:
The "require" function searches for Lua files in the same locations where the standalone Lua interpreter searches. We provide one extension to "require" in the Mako Server that enables you to load Lua scripts from Mako applications. The loader is by default disabled for the Mako application. To enable the loading of Lua script modules from your application, add the following line to the beginning of the Mako Server's .preload script.
mako.createloader(io) -- io is the Mako application's I/O interface
The loader enables "require" to search for files in ".lua", which must be a sub-directory in your Mako Server application. The loader works for deployed and non deployed Mako Server applications. Recall that a deployed application is a ZIP file and a non deployed application is a regular directory on your file system.
Note: the function mako.createloader() was added to Mako Server 1.4, which is currently not released. You can download an updated mako.zip, which includes this functionality.
The Mako Server example application requiretst.zip shows how to use function "require" with Lua modules in a Mako application. Download the ZIP file and start the Mako Server as follows:
The Mako Server consists of one executable file and one optional ZIP file named mako.zip. This file is required if you plan on using any of the following libraries: AJAX, SMTP, SOAP, JSON, XML-RPC, and the Web File Manager. These libraries use components developed in Lua and these components are packaged into mako.zip. The Mako Server automatically loads this ZIP file if found. This ZIP file should be in the directory where you install the Mako Server executable or in the directory where you place the configuration file. We recommend that you unpack and study this file. The file includes several additional resources such as the jQuery library.
Note: the mako ZIP file is also installed into the Mako Server's virtual file system using base URI '/rtl/'. You can access the resources in this ZIP file with a browser using the URL http://your-server-address/rtl/resource-name
The last print statement in the image to the right shows how the Mako Server loads the resouce ZIP file mako.zip. The image to the right shows how the ZIP file was automatically found by the Mako Server since the ZIP file is in the same directory as the Mako Server executable.
The Barracuda Application Server provides an IO interface in addition to the standard Lua input/output operations. These IO interfaces must be created by the "C" startup code, and the Mako Server startup code creates the following IO interfaces:
The following example shows how to list all IOs on the Mako Server:
for name,io in pairs(ba.io()) do print(name, ":", io:realpath"", " : ", io:resourcetype()) end
The above example produces the following output when run on Linux:
disk : / : disk POSIX home : ./ : disk POSIX net : nil : net vm : nil : zip zip
Returns a SharkSSL object initialized with the certificates in the the file .certificate/CA_list.p7b. The certificate file can be found inside mako.zip. A SharkSSL client object is required when creating a secure client connection such as an HTTPS connection or using the SMTP library in secure mode.
Returns a table with all apps loaded by the Mako Server. The following example restarts all applications:
Stops a registered application. Parameter x is either the application's environment or an index position returned by function mako.getapps().
Starts a registered application. Parameter x is either the application's environment or an index position returned by function mako.getapps().
Reloads the .preload script for an app. Parameter x is either the application's environment or an index position returned by function mako.getapps(). The following code snippet can be used by an LSP page to reload the .preload script for the app:
function mako.createapp(name, priority, path [,conf])
Dynamically create and load a new application.
Reload the SSL certificate(s) listed in mako.conf. The function enables an application to install new SSL certificates and then load the new certificates without having to restart the server. The Mako function loadcerts() is internally using the BAS function ba.create.servcon in the mode that enables it to recycle an existing server listening connection.
Change logfile name/location. This function enables you to dynamically change the name and/or location of the log file in a running system. The argument "name" is the full logfile name including the path, which can be a relative path or an absolute path. The function returns true on success.
Boolean value, set to true if the server runs in the background