On Tue, Mar 30, 2010 at 10:30 PM, Stuart P. Bentley <stu...@testtrack4.com> wrote: > So, CGILua was a sort of proto-Kepler Project, from before separate > libraries were used to handle each aspect of development?
Exactly. As Tomas mentioned, there were no "Lua modules" by then. The CGILua "distro" was somewhat similar to what we started doing with Kepler 1.0. Add to that the fact that "page generation" was a quite novel concept at the time. :o) > I guess what I'm saying is, I can't see what CGILua's "Lua Scripts" > functionality, as demonstrated under > http://keplerproject.github.com/cgilua/manual.html#scripts, adds to a bare > WSAPI script like samples/hello.lua to necessitate intermediary layers like > SAPI, and what it provides for > http://keplerproject.github.com/cgilua/libraries.html that keeps them from > standing alone. In the very first versions, CGILua was the bind to the webserver itself. First using CGI and, as a MsC experiment, ISAPI too. By the time we finally managed to fund Kepler, we considered ending the CGILua lifecycle but the existing users were clearly against it. :o) So, as an interim solution, we develope SAPI. SAPI was a simple API to abstract some of the web server details, but it was powerful enough to allow CGILua to move to new connectors like FastCGI, mod_lua, ISAPI, CGI and even Zope. Unfortunately, by the time SAPI evolved into WSAPI most of the other connectors were too outdated to be useful. So WSAPI ended with "just" FastCGI, CGI and Xavante connectors. In order to use CGILua with WSAPI, we simply wrote a new (and definitive) connector for SAPI (proving its value). > I think there's still, at its core, a thin layer that CGILua provides around > WSAPI (such as handling HTTP details like status codes and headers and > removing the need to design an iterator), but going forward, the way to fill > this role, from a design standpoint, should be to make a new library > designed with only these goals in mind, without the historical ties to CGI > and double-abstraction against WSAPI. Exactly our view. CGILua can be considered a PHP like solution, while Orbit would be a MVC based solution and Sputnik another different approach. While WSAPI was the first round of refactoring to unite those approaches, MK (the new module Fabio mentioned) is the second iteration of the same rationale. MK will handle dispatching, authentication, caching and form handling. Orbit is already being refactored to use it (reducing a lot of its current code base), but Sputnik and CGILua could also eventually decide to use at least some part of MK. One advantage of paving the road with a module like MK is that different frameworks can share the basic stuff, allowing for better interoperability. > What is SAPI, and what does it accomplish? This is one of the big points of > confusion for me. I REALLY can't understand the role of SAPI, except that it > seems to have been written to bridge the gap between the original design of > CGILua and WSAPI. Let me know if now its role is clear for you. > I could volunteer to "refactor" CGILua into smaller libraries if I had a > full understanding of what CGILua still provides that hasn't been superseded > by newer libraries. It would be great to have you helping with this refactoring of CGILua in the direction of MK. Note that this would the removal of not only SAPI but also some other parts of CGILua (even if you kept the old APIs for compatibility). Part of the revamp of the Kepler site is to try to better present the group, the projects and the layers involved with them. Currently the Portuguese site is more complete than the English one, but I'm trying to keep both in sync. André _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
