On Fri, Jul 25, 2008 at 10:57 AM, Fabio Mascarenhas <mascarenhas@acm.org> wrote:
> Oops, forgot to "Reply to all" when sending this... Lua scripts and Lua
> pages get a global environment for themselves in every request, but WSAPI
> applications do not, so any global you set can potentially stick around to
> the next request.

I think persisting state between requests is a good  thing, as long as
there is a way to control what's going on.  I tried a variation on
http://metalua.luaforge.net/src/lib/strict.lua.html, but the only
found a few globals in Sputnik, which I fixed.  (BTW, there are also
two globals in wsapi.ringer: "main_func" and "main_coro"  - are those
intentional?)

However, globals aren't really our problem here, I think.  There is
tons of state that is carried by the local "my_sputnik" inside
new_wsapi_run_fn(), an also potentially in module variables.  (Is
there a good way to control the creation of those?)

>> The bug is easy to reproduce on my setup, just edit a page (like the
>> configuration file) and change the main colour of sputnik... The
>> modification does not apply, repeatedly reloading the page gives
>> sometimes the expected result (the new color shows up) but not always,
>> while restarting xavante or touching sputnik.ws makes the modification
>> "stable". The bug is even nastries sometimes, since realoding may lead
>> the user to loose autentication (like if it was reusing a previous state
>> in which the user had not log in yet...).

In case of colors, the problem turns out to be quite simple: the
config node is loaded once, when "sputnik" object is created.  So,
this issue is specific to editing sputnik/config, etc.  Rather than
trying to detect if those files changed, I am thinking it might make
more sense to add an explicit way to reload the state.  So, I added a
new action ".reload", accessible only to admin, which forces
re-initialization of Sputnik.  So, after editing sputnik/config,
access sputnik/config.reload (or, actually, <any_node>.reload).  The
new settings will then be applied to the _next_ request.

With this change we are ok with CGI and Xavante.  With fcgi, however,
we've got an issue, potentially, since we might have multiple
processes, and the change in configuration would apply to only one of
them.  Not sure if there is any easy solution for this.

As for the authentication issue: we saw this one before, and I was
pretty sure we fixed it.  At least, I can't seem to reproduce it.
What version are you using?

 - yuri

-- 
http://sputnik.freewisdom.org/

On Fri, Jul 25, 2008 at 02:07:54PM -0700, Yuri Takhteyev wrote:
> On Fri, Jul 25, 2008 at 10:57 AM, Fabio Mascarenhas <mascarenhas@acm.org> wrote:
> As for the authentication issue: we saw this one before, and I was
> pretty sure we fixed it.  At least, I can't seem to reproduce it.
> What version are you using?

I was using 8.07.07. 

Cheers
-- 
Enrico Tassi

> I was using 8.07.07.

Then you should have that fix already (9754684b, the last commit that
went into 8.07.07)

Can you describe the exact steps?

  - yuri

-- 
http://sputnik.freewisdom.org/