It is bug squashing week at WSAPI central! I had to release yet another bugfix release today, to fix the bug introduced by the previous bugfix. In my eagerness to get the memory from unused states back as soon as possible I ended up killing perfectly good states, which would eventually leave the whole system unresponsive.

Either download news versions of the WSAPI packages from LuaRocks or download the updated WSAPI installer or the updated offline installer if you want to install without a net connection. I have deleted the installers and tarballs for the buggy 1.3 releases.

I have finally made new releases of WSAPI, which the changes that I alluded to in the last post, plus a few other changes and bug fixes. This is the changelog:

• Fixed memory leak with reload option for persistent loaders that was introduced by the new Lua state life cycle management
• Added raw HTTP responses to wsapi.common; useful when rolling your own HTTP server/proxy
• Fixed segmentation fault when non-string is provided to lfcgi.getenv() (thanks to mkottman@github)
• Added CGILua bootstrap to wsapi.sapi, so CGILua can run without a kepler_init module present
• Added an extra_vars paremeter to wsapi.xavante.makeHandler and wsapi.xavante.makeGenericHandler, to let you pass extra variables in the WSAPI environment
• Added overwrite option to wsapi.request that tells the parameter parser to overwrite repeated parameters instead of collecting them in a list
• Added a parameter isolated to the persistent generic loaders that controls whether you isolate each script in a Lua state or not
• Added parameters to the persistent generic loaders that let the user control the life cycle of Lua states: period sets how long WSAPI should wait between collecting stale states, and ttl sets the period after which a state becomes stale
• Fixed bug in wsapi.ringer that didn’t let you use wsapi.input:read inside the response iterator
• Parameter vars for the WSAPI generic loaders that which variables WSAPI should check to get the physical path of the script, and in which order. Defaults to trying SCRIPT_FILENAME first and PATH_TRANSLATED second

I have been doing a lot of web infrastructure work for Lua these past months, and pushing this WSAPI release lets me focus on mk and Orbit. There are still some uncommited changes to WSAPI in the mk branch, and this branch is where the development for WSAPI 1.4 is happening.

I hope I can find time to talk about what mk is and about my plans for Orbit 3 soon. Most of what Orbit 2 is has migrated to mk, and with Orbit 3 I want to raise Orbit’s level of abstraction.

Download either the WSAPI installer or the offline installer if you want to install without a net connection. Or download and install LuaRocks and luarocks install either wsapi, wsapi-fcgi or wsapi-xavante, depending on which way you want to launch WSAPI (CGI, FastCGI or Xavante).

The current HEAD of WSAPI has some nifty new features:

1. WSAPI has always encouraged the use of isolation between applications, with the Xavante and FastCGI launchers using Rings to put each WSAPI application/script in its own separate Lua state. This is great for avoiding applications stepping on each others toes with misuse of globals, but can be a performance hit if your applications are doing unbuffered responses.

   WSAPI 1.3 will include the isolated option to these launchers, set to true by default, to control whether you want isolation or not. Just edit your wsapi.fcgi and set isolated to false and all your applications will run in the same Lua state.

2. WSAPI’s standard request processing (wsapi.request) duplicates what CGILua used to do in case there is more than one field with the same name: creates a list with all the values of this field. WSAPI 1.3 adds an overwrite option to wsapi.request that makes the value of the field be the last value that appears, so all fields are always strings. If you want even more control, a builder option lets you provide your own behavior. A builder is a function (params, field, value) that is called for each field/value pair, with the table of parameters up to that moment, and mutates this table to do what it wants.

3. The WSAPI launchers try to detect whether the web server uses PATH_TRANSLATED or SCRIPT_FILENAME as the path to the script, but this is not foolproof, so there is now an option vars that lets you specify the order that WSAPI should check these variables, with the default being to check SCRIPT_FILENAME first.

There are also some fixes for non-critical bugs, that is why the next version is going to be WSAPI 1.3 and not WSAPI 1.2.1. I will be away for a week starting tomorrow, so I pushed the release to the week of 23-27 of November. What is missing right now is the implementation of the builder option that I outlined above, and changes to the documentation; right now these changes are documented in my exchanges on the Kepler mailing list.

Orbit’s orbit.model is an abstraction over LuaSQL that adds simple CRUD and parameterized queries, a sort of ORM super-lite. When you create a model, orbit.model introspects the database table that corresponds to your model and uses this metadata to do type conversions and build SQL statements.

Intializing models is very simple. The code below creates an orbit.model instance connected to an SQLite3 database, and then creates a model object backed by the todo_list table: