In a new post to his blog Gaylord Aulke talks about some of the "soft facts" that make PHP different from Java:

Besides the usual aspects: scripting vs. compiled and in-process vs. seperate process and Multithreading etc., i think there are some "soft facts" that might be even more important for commercial software development.

He points out things like differences in object lifetimes, defined structures in applications and the "not invented here" syndrome that he thinks PHP suffers more from.

Anyway, the result is: Even though there are not so many standards in the PHP world, successful developers have a common understanding about the do's and don'ts in PHP. [...] PHP appears more predictable than other programming languages.

Matt Wade has posted a quick item to APress' Inside Open Source blog today mentioning an update to an item he'd previously mentioned - issues with the Zend_Cache module.

One of my complaints was the Zend_Cache did not accept lifetimes on a per object basis, but rather the lifetime was at an application level. I just received notice in my inbox that the issue has been fixed! The change is currently in svn, and should be in the 0.80 preview release. Thanks go to Fabien for the fix.

You can download this latest version of the Framework (0.7.0) from the Zend Framework website.

Matt Wade has posted a quick item to APress' Inside Open Source blog today mentioning an update to an item he'd previously mentioned - issues with the Zend_Cache module.

One of my complaints was the Zend_Cache did not accept lifetimes on a per object basis, but rather the lifetime was at an application level. I just received notice in my inbox that the issue has been fixed! The change is currently in svn, and should be in the 0.80 preview release. Thanks go to Fabien for the fix.

You can download this latest version of the Framework (0.7.0) from the Zend Framework website.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.

From the CentreBlog today, there's an in-depth look at sessions as discovered by resolving a problem of prematurely expiring sessions on their apps.

It started about two weeks ago, with no discernable changes to our configuration that could be responsible. So to understand what was necessary to track down this problem, we have to explore a little bit about how PHP session data storage and expiration works.

They share some of their discoveries, including:

• the session.save_path setting in the php.ini tells the scripts where the sessions go
• garbage collection in PHP checks for sessions older than the session.gc_maxlifetime setting to remove
• but sessions were still expiring too early

They finally started to Google for some answers and discovered that the problem wasn't in the default PHP configuration, the real issue was other software that overrode this php.ini value inside each execution. The result was that a script with the setting of 45 minutes would remove all sessions untouched for more than 45 minutes - regardless if they belonged to other software or not.