[snip] ...interesting conversation... [/snip] Stateless applications, ain't they fun? I did a little experiment before Ajax cam into vogue with a small PHP script that essentially ran a while loop with some sleep cycles built in. This was placed in an iframe and another page was placed in another iframe with javascript to update the second iframe if data had changed in the first iframe based on a query running while PHP cycled the loop. OB functions were used and it worked. Clear? So that experiment lead to a meta-refresh of the page in the first iframe which then ran some PHP code that output some JavaScript to update the second iframe. It worked better, but had its moments. The point was to make the user experience better, a manager could see that certain things were happening without having to refresh a page manually. Also, a smaller more efficient query could be run and if the data had not changed the system would not have to endure the overhead of the larger query. The end result? A stateless application with simulated state....much like what Ajax does today. Really, it was as Ajax as could be, just not using the httpRequest doohickey, or whatever it is. There is a wide gulf between stateless applications and applications with state. Even Java uses a hacked stateless connection (by having something run client-side sending info a to listener on the server...what does that sound like?). Isn't the intent for client server apps to be stateless? Applications with state typically share memory resources. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
