Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19690 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22211 invoked by uid 1010); 22 Oct 2005 17:20:25 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 22168 invoked from network); 22 Oct 2005 17:20:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2005 17:20:25 -0000 X-Host-Fingerprint: 80.137.52.238 p508934EE.dip0.t-ipconnect.de Received: from ([80.137.52.238:9066] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 07/D4-22302-8D47A534 for ; Sat, 22 Oct 2005 13:20:24 -0400 To: internals@lists.php.net,Jani Taskinen Message-ID: <435A74D9.1080400@web.de> Date: Sat, 22 Oct 2005 19:20:25 +0200 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 CC: Sebastian Bergmann References: <42FCE0E4.604@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.137.52.238 Subject: Re: [PHP-DEV] PHP 6.0 Wishlist From: akorthaus@web.de (Andreas Korthaus) 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 ;-)