Talk:Tasks

Kepler interpreter

Currently Kepler assumes the Lua interpreter as the way to execute scripts. While this may seem a reasonable approach at a first glance, it leaves us with some problems:

• Kepler paths as not exactly equal to Lua's
• Kepler is usually used in a separated context, where Lua's defaults may not be the best choice
• There is no standard Lua paths on Windows

While the usual suggestions for handling those problems evolve around the use of the LUA_INIT environment variable, I think that we may choose a more explicit way to handle the Kepler environment. My suggestion would be something like:

• Offer a separate interpreter for Kepler, where it would be explicit assumed that the paths would be different from Lua.
• This interpreter (Yuri suggested that we call it klua) would set package.path and package.cpath by invoking a kepler_init.lua script. The interpreter would look for a kepler_init.lua file in the current directory and load it if found. Otherwise it would check for the existence of a KEPLER_INIT environment variable and load the script pointed by it if found. Otherwise it would load the default kepler_init.lua script installed by Kepler.

Once we have this in place, we could garantee that executing a script using klua would find the correct libraries into the Kepler space, even if it coincides with the Lua one. On the other hand, on Windows installations and user space installations on Linux things could be a lot easier for newbies.

Module testing

One use of klua could be a standard way to run module tests. Currently the tests are distributed with the modules, but not installed. And running them depend on having the Lua paths acessing the Kepler modules.

Again, this may not be strange on a Linux root installation, but on Windows and user space installations this may present some problems.

Ideally one should be able to install Kepler with an option to include tests, change to the /kepler/tests directory and run klua test.lua modulename or klua test.lua in order to run a module test suite or to execute all the available tests.

In order for that to work, the install script would have to copy the module test scripts to /kepler/test/module. There would also be a test.lua script that would check for a module name as a parameter and run the test.lua script in the module directory. Otherwise it would iterate over the directories and execute each of the suites in sequecence.

The way tests are being done now, this kind of all tests would be not very practical since the scripts are assuming a per module execution, but we could change this with time in order to provide a more nice view of the tests results.

CGILua and URLs without .lua or .lp scripts

Currently CGILua always uses the directory returned by the underlining web server, but it would be important to make both CGI and Xavante launchers use the Kepler htdocs directory instead.

This would make it a lot easier for users of Kepler on hosts that do not offer more sofisticated launchers.

A related and more important issue concerns flexibility with the CGI launcher. Currently the CGI launcher allows URLs like server.com/cgi-bin/cgi/app.lua?param=1 but this requires that app.lua is located at the public HTTDOCS directory of the web server.

If instead CGILua used a CGILUA_SCRIPTS variable defined on kepler_init.lua it would be possible to leave app.lua anywhere in the system without making it easy to eavesdrop using server.com/app.lua.

Note that the more sofisticated launchers allow a greater level of control on where the app.lua file is located, so this is usually not a problem. But the CGI launcher currently lacks this power.

Finally, we could also change the behaviour of CGILua when handling a URL without an explicit page or script for it. Consider the URL server.com/cgi-bin/cgi?param=1. The current version of CGILua considers an error and aborts the processing. But if instead it looked for a file called cgi.lua in the CGILUA_SCRIPTS directory, this would allow for a very easy way to do MVC like controllers with the current version of CGILua.

If you wanted to create a controller called app, all that you would need would be to copy the cgi executable installed by Kepler (assume a user space installation for example) to app and then when a URL like server.com/cgi-bin/app?param=1 was used, CGILua would look for app.lua not in the HTTDOCS directory, but on the CGILUA_SCRIPTS one.

• For extra credit, renaming (or symlinking) cgi and to myapp.cgi, and then calling http://server.com/myapp.cgi should call myapp.lua instead of cgi.lua. -Yuri

Once this was in place, one could create new applications by simply copying the launcher with different names (this may even work with symbolic links, not tested). - Andre Carregal