Re: CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)
jbv- Wednesday, November 29, 2006, 2:41:46 AM, you wrote: > 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... Yes, it can be done. The problem is that then you're hand-crafting a web app written in rev. Nothing wrong with that, but the same app is probably not going to run as a desktop app and as a cgi backend. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)
Robert- Wednesday, November 29, 2006, 4:13:09 AM, you wrote: > Actually, single-threading of Rev comes handy here. At any given > moment, the program can run only for a single user, so as long as all > user-specific data is passed as arguments and the any data that needs > to be preserved is kept in a backend database, there is no problem. ...and then it's no longer a rev app, it's a cgi app written in rev and hand-crafted for a web environment. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)
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. -- Actually, single-threading of Rev comes handy here. At any given moment, the program can run only for a single user, so as long as all user-specific data is passed as arguments and the any data that needs to be preserved is kept in a backend database, there is no problem. If globals have to be used, then tagging data by some userid or session code can allow differentiation. This works particularly well when user actions can be atomized into individual actions which do not require larger chunks of server time. Robert ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: CGI remark (was : Revolution and the Web, feedback wanted, Part 1 of 3)
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. > > -- ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
