I took a quick look at the module and found this in phpfreechat_room: if (is_numeric($user->uid)) { $_SESSION['drupal_user'] = $user; } This creates a lot of overhead. The user object can become really large depending upon what different modules are doing things with it. I looked through the code and the only part of the user object I see being used is $user->uid in phpfreechat_prepare_params(). I don't even see any real reason to store the uid, since you have the global $user that is going to be available for that session. I would say a good starting point is dumping that all together, since you have a global $user that gets loaded when the session is loaded. Jamie Holly Sheryl (Permutations Software) wrote:
If any of you guys want to take a break from dissecting OG, I'd deeply appreciate thoughts and ideas about my sessions problem. Some questions:
1. I put the session_save_session(FALSE); line at the top of the phpFreeChat module code, and it broke phpFreeChat. Was this the right place to put it?
2. How could phpFreeChat - a standalone program - be dependent on what Drupal saves to its sessions table? Seems to me it can't. That's why I think something must have been wrong in how I tried to disable sessions writing.
Thank you.
- Sheryl