>> On developer's machine I change code often, and it is rather
>> inconvenient to run an extra command before refreshing browser window.
>> Perhaps it is possible to disable caching for such cases somehow?
> Well, if you set reload in wsapi.fcgi to true you will turn caching off
> completely. You can have wsapi-devel.fcgi if you want to keep things
> separate. With spawn-fcgi you don't even have to change your nginx config to
> change wsapi.fcgi scripts, just kill your workers and spawn new ones.
Thanks, I'll try that.
<...>
>> Would be great, thanks! Those zombies are surely looking hungry for
>> our admin's brains :-)
> Already in github.
Wow!
>> >> 3. I can't supply a callback to WSAPI without wrapping it in a Lua
>> >> module. I'd like to avoid this.
>> > ---- hello.lua
>> > local function hello(wsapi_env)
>> > return 200, { ["Content-type"] = "text/html" },
>> > coroutine.wrap(function ()
>> > coroutine.yield("<html><body>Hello!</body></html>") end)
>> > end
>> > return hello
>> > ----
>> > No need for a module. :-)
>> Wow! Thanks. Is it documented?
> Well, Lua modules actually work this way, too (require "hello" where
> hello.lua is this will return the hello function),
Well, Lua manual documents modules as a bit more complex structures
(at least I've had an impression that module MUST be a table...)
So, hello.lua is not a module, but require would still support it (as
dofile or loadfile would). I never thought about this...
> and WSAPI itself is about
> handler functions, not modules (modules are a convenience that the launchers
> give), so I didn't feel the need to document this.
I think this should be documented. Ability to do this gives more
light-weight feeling to WSAPI. I think that is good.
> The Orbit (http://github.com/keplerproject/orbit) samples are a good source
> for docs on WSAPI, too, as Orbit apps are WSAPI apps. You will see apps
> written in this style (no module).
Does documentation mention that? :-)
>> >> 5. WSAPI handles duplicate request keys by putting all their values
>> >> into a table. I need to get more PHP-like behavior, when next value
>> >> for the duplicate key would override previous one. I had to copy and
>> >> change the request module to get this behavior. I do want a
>> >> configuration option.
>> > Ok, this can be an option to wsapi.request.new:
>> > req = wsapi.request.new(wsapi_env, { overwrite = true })
>> That is my pet feature request. I'm a bit nervous about copying of
>> that lot of WSAPI code to my project.
> Already in github.
Cool! Will give it a try tomorrow.
>> > I am thinking of adding an option for wsapi.fcgi in WSAPI 1.3 that will
>> > makes applications persistent but not isolated (all applications in the
>> > same
>> > FastCGI process share the same Lua state). This should add minimal
>> > overhead
>> > compared to the whole isolation thing.
>> I'm planning a very thin single entry-point FCGI layer now, so
>> non-isolated applications should not be a problem. (After all I always
>> can do my own sandbox, can't I?)
> Sandboxing in Lua is pretty easy, compared to other languages. :-)
Indeed! :-)
Fabio, thank you! Your support for WSAPI is fantastic! You're fixing
my complaints almost faster than I actually report them! That is
really cool! :-)
Alexander.
_______________________________________________
Kepler-Project mailing list
Kepler-Project@lists.luaforge.net
http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project
http://www.keplerproject.org/
