World: r3wp

The main point is that G-WAN basically uses the BeOS/Syllable architecture: 
one process with worker threads

That's what I plan to do too for Red.

Specifically, it uses a pool of one thread per core for an event 
based architecture

That's the only rational way to use threads IMO too.

Well, there you have it: the other web servers don't

Sqlab, G-WAN for Windows is discontinued, a year ago or so

Yes, but I just used the examples as they are explained in the manual 
for the windows version.

It seems to have been developed on Server 2003. Maybe it doesn't 
work on newer Windows versions. It was discontinued in September 
2009

That was probably when G-WAN had been in development for a year, 
so in any case it would be incomparable to the current Linux version, 
which is not mature yet, either

Just one question, nothing urgent. Would it be possible or smart 
if cheyenne would return http 401 to ajax request when the session 
times out? Now it basically return 200 and login form html (so I 
have to test for presence of </form>) instead of usuall JSON.

How can Cheyenne know that's an "ajax request"?

It should be possible to either extend the AUTH config option to 
specify an "ajax" mode or to add a new AUTH-AJAX config option.

yes, that question crossed my mind :) ... maybe this should hold 
only if request has: "Accept: application/json"

or like you check now it here is any html returned in debug more, 
if not you don't render the debug bar

What if the request has other mime-types in addition to that one? 
:-)

Cheyenne doesn't return HTML when a session times out, it only returns 
a 301 (or 302, I don't remember) to the URL you've specified in the 
config file after AUTH.

So, there's nothing to parse there for Cheyenne.

yes, I agree it's not so straightforward .. you could only redirect 
when there is accept: "*html*" ..

yes, that is true.. you make a redirection

So, if you redirect to an AJAX-generating script, it should be ok 
(depending how your application is handling login).

but XMLHttpRequest isn't able to return any of 30* codes .. in case 
of 30* it automatically redirects and returns the result with 200

So, if you could specify, for example: AUTH <http code> (instead 
of providing an URL), would it work with XHR?

In such case, Cheyenne would just return an HTTP code with no content 
and would let the client handle the redirection to login form (or 
whatever other action is suited).

as I say, it's not a practical problem for me. :) Just a suggestion.. 
I am making external API and I got some developers that are very 
sensitive to propper HTTP so I am rewriting my api to all those codes.. 
But this is not a problem for that, since API doesn't use cheyenne's 
sessions.. just while I am rewriting my ajax code I thought of it.

I can detect all other codes with XHR yes, except 3* ..  so if server 
returned 401 without content JS would then make what is appropriate.

In the next days, I will spend a day or two on Cheyenne, to fix a 
few pending issues (like the broken websocket compatibility after 
latest RFC changes).

If you need it, I should be able to add it easily.

If you think there's a more general solution to this use-case, let 
me know.

This was my old code because ot it (I check for </html> and </form> 
to see if I signed out) . Now I am making it status for validation 
for example it will be status 403, etc ..


    onChange2: function(rq, pars) {
        this.assureLANG();
        if (rq.readyState == 4) {
            if (rq.responseText) {
                if ( rq.responseText.indexOf('</html>') > 0 ) {

                    if ( rq.responseText.indexOf('</form>') > 0 ) {
                        alert(LANG.err.session_exp);

                        window.location = window.location.href.replace(/#.*/g, "")+"";
                    } else {
                        alert(LANG.err.ajax_err);
                    }
                } else {
                    c(r.responseText);
                }
            } else { this.onError(); }
        }
    },

--

You really don't have to change it now .. you can add this any time 
later when it maybe clears out even better .. I don't want to keep 
you from RED

Cheyenne was serving me well for all this time and this is no real 
issue .. just a notice for future maybe

Well, the biggest task is getting websockets up again, modifying 
AUTH should really be a matter of a few lines of code.

I also need to review PHP support as I will make a Cheyenne presentation 
next week at a big PHP meeting here.

So, I will spend at least a day on it.

I quickly mocked up how ajax code would look if you made it return 
401

    onChange2: function(rq, pars) {
        this.assureLANG();
        if (rq.readyState == 4) {
            if (rq.status == 401) {
                alert(LANG.err.session_exp);

                window.location = window.location.href.replace(/#.*/g, "")+"";
            } else if (rq.status = 200) {
                success(r.responseText);
            } else if (rq.status == 403) {
                validation(r.responseText);
            } else {
                this.onError();
            }
        }
    },

well .. you decide .. for me it's not a problem, really .. and I 
am also starting to think about HTTP codes now so I don't have the 
clearest view yet

hm.. same would be then for error, again when in JSON mode .. instead 
of html explanation you should return 500

but yes, the question is what is the best way to determine the JSON 
mode (or XML or CSV or ...)

Precisely. :-)

I will have a lot more experiences about this in few months because 
I am just working on this stuff regarding the API and export. I used 
aditional get param so user can select what format she wants. But 
I was educated by this guy that I should look at Accept headers, 
which I ignored happily ..:) .. same about statuses which I didn't 
use. Now I am getting home at this, so we can talk in a while and 
determine the most systematic and clean way for this. And such that 
will make the REST purists happy

I'm looking forward to it!

Ok, great.. I will get by when time comes

I think that Gabriele could also have some good inputs on the best 
practices to support, as he's doing a lot of AJAX programming.

great

My main server is down since a few hours due to a non-technical issue. 
This affects all the following web sites:
- cheyenne-server.org
- curecode.org
- part of red-lang.org


The problem should be solved in an hour. This server is still owned 
by my former company, Softinnov, who forgot to do the renewal in 
time.

Ok, server is up again, issue solved.

Too bad I thought it was a hardware issue and I sent a reboot from 
the control panel, just a few seconds before realizing that the server 
plan has expired. The server was running since 670 days uninterrupted.

I want to log certain events from the webapp. What would be the most 
efficient way to do this (by this I mean one that would have least 
impact on server responsivenes). I would like to use something silimar 
to debug/probe debug/print .. Is it possible to have use the existing 
loging functionality to log custom stuff to custom log? (or is this 
just normal file append)?

I think its ok to use append if its not a heavy-loaded web site. 

I did this to prevent possible file access problem if it happens 
same time in very rare cases:

		unless 'ok = loop 3 [
			if not error? try [
				save voter-file append voters session/content/username
			] [
				break/return 'ok
			]
			wait 0:0:0.1
		] [
			response/redirect "error.rsp?code=error-on-voting"
		]

You can use debug/* logging functions, but they will only log in 
%trace.log file. Writing directly to a log file from RSP script is 
unsafe (unless you take great care about concurrent accesses). So, 
if you want to have custom logs from RSP scripts, you should use 
the OS syslog service for a really realiable solution. The debug/* 
log functions use their own solution for serializing disk writes, 
they are passing data to Cheyenne main process that does the writings 
to disk.