[Sputnik-list] Versium, which repo?

[Yuri Takhteyev]

I am glad we are roughly on the same page, then.  I still think this
is the wrong list for this discussion.  Why don't we move it to the
Kepler list?  I think it's important to first work out what the
strategy would be for packaging Kepler for Debian, and then think
about Sputnik as just another Kepler application.  I will then make an
effort on my side to ensure that it works as its supposed to.

I am thus not the best person to answer the question of advantages of
WSAPI over SAPI.  The reason I am myself eager to move to WSAPI mostly
has to do with the fact that it allows to use CGI the "normal" way.
Up to the last Kepler snapshot, cgi had to be used via a cgi binary,
which magically called CGILua, which then called whatever script was
specified in the URL.  I find this confusing, since this is not how
CGI normally works.  In comparison, the new snapshot uses a much more
conventional approach - a lua script that starts with shebang.  The
default version is a bit more complicated than I would want, but it
could be replaced with just the following:

    #!/home/yuri/tmp/sputnik-3/bin/lua5.1
    loadfile("/home/yuri/tmp/sputnik-3/etc/kepler/1.1/kepler_init.lua")()
    require"wsapi.cgi"
    require"wsapi.sapi"
    wsapi.cgi.run(wsapi.sapi.run)

Or, alternatively, one can paste the needed parts of kepler_init.lua
directly into the cgi script:

    #!/home/yuri/tmp/sputnik-3/bin/lua5.1
    KEPLER_DIR="/home/yuri/tmp/sputnik-3/"
    KEPLER_CONF = KEPLER_DIR.."/etc/kepler/1.1"
    KEPLER_WEB  = KEPLER_DIR.."/htdocs"
    KEPLER_TMP = "/tmp"
    CGILUA_CONF = KEPLER_CONF.."/cgilua"
    CGILUA_TMP = KEPLER_TMP
    local libext = [[so]]
    package.path =
KEPLER_DIR..[[/share/lua/5.1/?.lua;]]..KEPLER_DIR..[[/share/lua/$
    package.cpath = KEPLER_DIR..[[/lib/lua/5.1/?.]]..libext..";"..package.cpath
    require"wsapi.cgi"
    require"wsapi.sapi"
    wsapi.cgi.run(wsapi.sapi.run)

This leaves us with two levels of indirection, however: wsapi.sapi.run
will end up calling cgilua, which will load cgilua/config.lua and then
execute the lua script that would actually call sputnik.  With WSAPI,
there would be no such indirection:

    #!/home/yuri/tmp/sputnik/bin/lua5.1
    KEPLER_DIR="/home/yuri/tmp/sputnik/"
    local libext=[[so]]
    package.path=KEPLER_DIR..[[/share/lua/5.1/?.lua;]]..KEPLER_DIR..[[/share/lua/5.1/?/init.lua;]]..package.path
    package.cpath=KEPLER_DIR..[[/lib/lua/5.1/?.]]..libext..";"..package.cpath
    require("luarocks.require")
    require"wsapi.cgi"
    require"sputnik.web.wsapi_app"
    wsapi.cgi.run(sputnik.web.wsapi_app.run)

So, for me it's not about size, but about complexity.  Note that the
first few lines (the ones setting up the paths) would depend on how
the packages are managed.  Such a script could use it's own package
tree or just whatever is available in the system.  "sputnik" in this
case is just a Lua package (installable as a rock or using whatever
other way).

> Wsapi brings with it a lot more, I divided the package in two so that
> the fastcgi part is not required by default but it still depends on
> rings, thus I don't see wsapi as something much smalled then cgilua, but
> more as an extra layer to put between the web server and cgilua to

I seem to have managed to convince Fabio to similarly divide WSAPI
into rocks: the all-lua basic WSAPI, plus a separate one for fastcgi
that requires compilation.  I don't know if WSAPI can be used without
Rings.  I hope so.

> Colors, I don't know what it is meant for...

It's a library that does color calculation in HSL color space.  It
also allows you to calculate "harmonious" color pallets using "color
theory."  I use it in Sputnik to generate a color scheme from a single
hue value.   You can package it together with Sputnik if you prefer.

- yuri

-- 
http://www.freewisdom.org/