CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)

[jbv]

Mark,

I'm not sure to fully grasp the full extension of your remark (as I haven't
used fastCGI yet), but as for separating 2 users' requests, this can be done
easily by issueing a unique ID code to each user, and sending it along
with each cgi request... Maintaining a table of logs with those unique IDs
inside a DB can be usefull as well if you need to force users to re-log
every 15 min or so...

I might be missing something, but I wouldn't call this "a lot of frontend
and backend coding"...

JB

> Mark Wieder wrote :
>
> Once you use fastCGI that problem disappears, as the engine is always
> in the server's memory, so it's like never closing the stack. But now
> you have problems separating the two users' namespaces. And since the
> variables are persistent, interleaving the two users' requests is
> going to get garbled. There's no way to keep them in separate places
> without a lot of frontend and backend coding. And that's just two
> users - it becomes a lot harder as you try to scale it. If you could
> thread user requests then this would resolve to a much simpler case.
>
> "Send in time" also probably requires multithreading, if it can be
> done at all. It's similar to the blocking problem conceptually. And
> any of the blocking calls will bring a fastCGI system to a halt and
> prevent multiuser access.
>
> --