Jani Taskinen wrote:
>
On Sat, 22 Oct 2005, Sebastian Bergmann wrote:
Rasmus Lerdorf schrieb:
Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
In case we include APC by default, it would be nice if its apc_store() /
apc_fetch() mechanism could be mapped to a new super-global, say
$_PERSISTENT[].
Containing what?
A super-global like $_PERSISTENT could work like $_SESSION, with a
similar "framework", but could store data which is NOT user-specific
like session-data.
So you have a very simple methode to store any variables/objects between
HTTP-requests. If you use something like APC as backend, you will also
get a fast methode to store/load variables/objects, which are not
user-specific, and perhaps expensive to create/load (e.g. from a
webservice, DB...).
The problem with "several machines serving same web pages" is exactly
the same you have with $_SESSION today. But the session extension
provides means to work around this using a DB or memcached as backend.
This could be copied by something like a "Persistance Framework".
But many other PHP installations will have another problem you don't see
with $_SESSION today: concurrency. That's because you don't have a
unique session-ID anymore, so application1 can overwrite variables from
application2, script1.php can overwrite variables from script1.php and
on shared hosting setups user1 can overwrite variables from user2.
That's also a security issue.
So an application-ID has been a good idea, but if you have to define it
by yourself, chances are that two users choose the same application-ID
and applications will break. So perhaps you also have to find some other
values, the users cannot control, to avoid concurrency issues. Perhaps
make a $_PERSISTENT variable only available for the script which has
created it (by saving the path too, but if you move/rename..., and not
very flexible anymore).
Best regards
Andreas
PS: I've read the discussion on this list before ;-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
