Description:
------------
The default serialisation scheme in php for session data is different than that provides by php to the scripting environment. While on one scale it uses the "userland" serialisation format overall it uses its own scheme that is very hard to parse safely without writing a grammer.

There are existing functions that can serialise/deserialise session data using the session scheme. However they are not flexible and can lead to risky code. These functions are session_encode and session_decode. Their short-fall is that they do not let the programmer choose where the data is deserialised/serialised to or from. It always works with the $_SESSION global.

I submit a simple proposal to provide functions to serialise session data with the same level of flexibility as the conventional serialisation functions.

An example of how the functions might appear (pseudo):

String|false session_serialize(Array* $in_assoc_array);

Array|false session_unserialize(String $serialized_data);
Or:
Boolean session_unserialize(String $serialized_data,Array* $out_assoc_data);

Of course another suggestion would be to use normal php serialisation on the whole array rather than just it's members.

Thanks.

Reproduce code:
---------------
		$result=$db->query('SELECT * FROM sessions WHERE user='.$recipient);
		$oldsession=session_encode();

		while($session=$result->object())
		{
			$_SESSION=array();
			session_decode($session->data);
			++$_SESSION['menu']['inbox'];
			$db->query('UPDATE sessions SET data="'.$db->escape(session_encode()).'" WHERE id="'.$db->escape($session->id).'"');
		}

		$_SESSION=array();
		session_decode($oldsession);

Expected result:
----------------
As this is a feature request the code does exactly what is expected. The code here is an example of the current system. Actually result contains the downfalls of this.

Quick redundant note. This code may not be the best example (one might argue that the counter should be stored elsewhere) but was the closest one to hand.

Actual result:
--------------
While it works fine it is somewhat risky. Loading the data to the current session is beyond requirement. If an inexperienced developer were to alter this code it could result in a mistake such as breaking the restoration of the session that causes the user submitting the post to adopt the session of the recipient. It is also somewhat inefficient as the existing session data should not really need to be backed up and restored. I did try just copying the global to another variable and back again but this somehow resulted in the user being logged in as the recipient. I decided to play it safe after that and serialize/deserialize it instead.

With a custom save handler it could be possible to implement a security switch. However, this is far from elegant.