Re: Session management module: how ASP does it

> Ok, at this point, I guess we should start finding people that want to > actively work on that project. Any volunteers? Hi :-). I signed up on the PHP-DEV a couple of months ago with the intent to work on the session/application objects. Due to time constraints, I decided to wait until the summer to work on this. Because it is now the summer =), I have more time to actively develop this. When I spoke with Stig Bakken March/April, one idea that seems really cool is implementing a separate RPC server that allows PHP to store session and application data and possibly even call PHP scripts on the RPC server. Here is what I would like to see: When you want to use a session variable, you can either use the session_variable() function or, if you're making a script from scratch, declare variables as "session" or "application" (or "app" if that's too long). Here's an example: <?application static unsigned int nVisits; application static critical_section csVisits; if (!csVisits) application_createCriticalSection(&csVisits); application_enterCriticalSection(&csVisits); nVisits++; application_leaveCriticalSection(&csVisits); session static unsigned int idUser; session static MYAPP_ORDER *orders; session static unsigned int nOrders; if (!session_initialized(&idUser)) idUser = request.form("userid"); // or however you get form variables (I haven't written in PHP yet, just ASP :-( // again, I apologize for the ASP-like code below; bear with me: unsigned int i, t; response.write("You have %lu items in your shopping basket</td></tr>\n<tr><td>", nOrders); for (i = 0; i < nOrders; i++) { if (i > 0) response.write("</td><td>"); response.write("<b>Order %lu</b></td></tr>\n<tr><td></td><td>", i); response.write("</td><td><b>Item</b></td><td>Price</td><td>Quantity</td><td> Line Total</td></tr>\n<tr><td></td><td>"); for (t = 0; t < orders[i].nLines; t++) response.write("Item %lu</td><td>%s</td><td>$%.2f</td><td>%lu</td><td>$%.2f</td></tr>\n<tr><td></ td><td>", t, getDescription(orders[i].line[t].idItem), getPrice(orders[i].line[t].idItem), orders[i].line[t].nItems, (double) orders[i].line[t].nItems * getPrice(orders[i].line[t].idItem)); } ?> If you want to declare static variables within functions as session, then use the session type modifier. If you want to access these variables from other pages, simply use the same declaration with the same variable name. The RPC server would store variables using the type and name as a concatenated key, such as "int nOrders". Here are some extra functions that can manage these variables: session_initialized() // was the session started? session_initialized(&variable) // was this variable initialized (if it was not assigned a value yet, it returns zero) session_uninitialize(&variable) // uninitializes a variable and frees any memory associated with the current value (done automatically when the session expires or when the session is uninitialized completely) session_uninitialize() // uninitializes all session variables (almost like Session.Abandon in ASP) The critical section functions that I mentioned in the code can allow mutex operations on global variables easily and efficiently :-). For storage of this data, refer to the current source code for the RPC server in functions\rpc.c, functions\rpc_protocol.c, and functions\rpc_protocol.h. The PHP server, if not running as a persistent server module, would contact a separate program that is always running to exchange serialized data. For installations where the PHP server is running as a server module, the RPC server can be within the module and/or external. The global properties and/or scripts can specify which RPC server to use as well as the default one to use if the script doesn't care. All storage is memory-based, and if the server runs out of memory, the swap file/partition of the operating system is used without any effort on our part ;-). This way, we avoid the complexities of storing everything to files while making this really fast in the process :-). Isn't that why web servers typically have gobs of RAM in the first place ;-) (other than caching, etc). The RPC server would actively perform the process of expiring stale sessions and objects. In addition to object/variable management, the RPC server could also generate unique session IDs without having to worry about the small possibility of collisions. The script could use this as the session ID to send to the client or the script could use its own methods. If you have an RPC server that is external from the PHP module (if running as one), then multiple web servers can access that RPC server if the security permissions are set that way. With this, if a server goes down and a client is automatically sent to another web server via router/gateway magic, the PHP script on the other server can use the same variables and data that the other server was using with that client/session. With this capability, ASP shops might take a closer look at PHP :). Furthermore, we should give PHP developers the option to either use session/application objects easily (as above in my code example) or manually (as in the previous e-mails). This actually makes it easier than ASP! And that's what we need to win developers over.. The _only_ thing holding me back from PHP is the lack of good session management, and with the ideas in this e-mail and the other e-mails in the last couple of days, my ASP days will soon be over, and many others too ;-). --Steven Lawrance-- Personal Web Site and E-Mail: slawrance@technologist.com http://www.bryant.edu/~ssl2 (SSL2) -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net