Overview
Kepler uses a very modular architecture in order to satisfy its requirements:
- Installable on most of the systems out there, from routers to web farms.
- Installable in the user space for those who do not have root access.
- Installable as part of the application itself.
Most Web frameworks usually require that someone first install the framework as a system wide resource so developers can access it. Although Kepler can also be installed like this, one of its advantages is being able to offer more scenarios to developers.
Dealing with different systems
The first requirement implies not only portability but also integration with various Web servers using different APIs (CGI, FastCGI etc), so Kepler offers a single connection point with the Web server called a launcher.
A launcher is a C module that interacts with the underlying Web server using some API and exports a common interface called SAPI. SAPI is a set of Lua functions that allow Lua modules to communicate with the Web servers without having to know any of their specificities.
A typical example of such a Lua module would be CGILua. CGILua uses a traditional page based model and generates content using SAPI as the low level API.
Running within user space
To be installable into a user space in Unix, Kepler offers a lot of customization options during the installation process and does not require root access to the system.
A typical example would be a user that has an account in some ISP that does offer any Web options other than CGI on a cgi-bin directory.
Depending on what services and APIs the user has access to, Kepler can be configured to run as a local CGI process or can use more sophisticated options such as FastCGI or mod_lua. Note that from the point of view of the application being used, this does not make a difference.
Being part of the application
While the above methods can be described as installing a framework for applications to use it, Kepler can also be distributed as part of the application. In that scenario, the user installs the application and may not even be aware that Kepler is part of it.
A typical example would be a system like Sputnik, where the application package contains all the elements of Kepler necessary for its execution.
Note that a user can even install more than one Kepler application that way, not knowing that different copies (or even versions) of Kepler are being used inside them.
Choosing a scenario
As the above scenarios showed, Kepler can be used in quite different ways. Choosing which model to use will depend on how much you are assuming of your application users.
If your users are system administrators or if you are installing Kepler on your own machine, then a system wide installation would probably solve it. If your users understand enough about configuring a Web framework but are not system administrators, a user space scenario would fit better. Finally, if they are not supposed to deal with details or if they don't have access to a shell, embedding Kepler into the application could be a good choice.