Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:3797 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90933 invoked by uid 1007); 7 Aug 2003 13:15:13 -0000 Message-ID: <20030807131513.90932.qmail@pb1.pair.com> To: internals@lists.php.net Date: Thu, 07 Aug 2003 14:15:12 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3; MultiZilla v1.4.0.4A) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030807123647.61433.qmail@pb1.pair.com> <008b01c35ce3$3bc1bcf0$1601a8c0@andreywin> In-Reply-To: <008b01c35ce3$3bc1bcf0$1601a8c0@andreywin> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 81.79.62.69 Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables From: davey@php.net (Davey) Andrey, > // masv = my application shared vars. This is the name of the shared var. > // Only the first 4 chars are used to calculate memory address. > $_APPLICATION = new Shm_Protected_Var("masv", 1024 /*memory*/); > $_APPLICATION->start_section() > var_dump($_APPLICATION->getVal()); > $_APPLICATION->end_section(); This isn't quite as transparent as $_SESSION is and $_APPLICATION would also not be a superglobal. What I would like to see at the end of this is a $_APPLICATION variable (or $_APP? some poeple complained that $_APPLICATION is too long) that behaves *exactly* like $_SESSION (in assignment etc) except that its values are available not across sessions but across applications and instances of applications. - Davey Andrey Hristov wrote: > Hi Davey, > I don't know whether this will be implemented in an extension but > there are sollutions in userland : to use sysvshm+sysvsem or shmop. > The sysvshm+sysvsem extension exposes the C api. > I know for 2 wrappers around this API to make the use of shared > memory (and thus something like application wide variables) easy > to implement in userspace: > 1) > http://www.php-tools.de/site.php?&PHPSESSID=b4a4ab7142b7d3209c7eee9769120cba > &file=patMisc/shmc.xml > 2)http://www.hristov.com/andrey/projects/php_stuff/shm.php.gz > > The second one is written according to PEAR CS. It exposes 4 classes. > Shm_Protected_Var is what is needed to implement $_APPLICATION: > > // masv = my application shared vars. This is the name of the shared var. > // Only the first 4 chars are used to calculate memory address. > $_APPLICATION = new Shm_Protected_Var("masv", 1024 /*memory*/); > $_APPLICATION->start_section() > var_dump($_APPLICATION->getVal()); > $_APPLICATION->end_section(); > > Regards, > Andrey > > > ----- Original Message ----- > From: "Davey" > To: > Sent: Thursday, August 07, 2003 3:36 PM > Subject: [PHP-DEV] [Proposal] Idea for Application level variables > > > >>Hey, >> >>I'm quite new to this, so please don't shoot this down too harshly. If I >>don't explain something clearly enough, please ask me. >> >>Because Application variables are pretty much shared session variables, >>I wonder if perhaps the session code can be modified to handle these >>variables. >> >>In userland, the implementation would be similar to sessions, and can >>work on two levels, for a single file or for a group of files. >> >>Userland usage examples: >> >>// cross file (i.e. an entire website) >>application_vars_start('my_website'); // my_website is used as the SID >>$_APPLICATION['website_users'] += 1; >> >>// single file >>application_vars_start(); // uses filename based SID, see below >>$_APPLICATION['page_users'] += 1; >> >>I figured that by using the following in place of the user-input SID, >>you can easily have page-wide application vars, and by using the arg for >>application_var_start() in the the place of >>SG(request_info).path_translated you can have it across whatever you >>like, problem is when you have multiple sites on the same server, >>someone else might choose the same name >> >>PHP_MD5_CTX context; >>PHP_MD5Init(&context); >>PHP_MD5Update(&context, SG(request_info).path_translated, >>strlen(SG(request_info).path_translated)); >>PHP_MD5Final(key, &context); >> >>I don't know if this is clear enough, but in my head at least, it seems >>a inexpensive solution to something PHP is (in some peoples opinion) >>lacking. (Note: SRM seems like overkill just for this). >> >>Another nice thing about this, as it'll be using the Session >>infrastructure it could use the session handlers aswell (sqlite, mm etc) >> >>one problem that has been mentioned is multi-threaded situations, but I >>would assume that either the current session code doesn't suffer from >>this (and therefore neither will this) or that the session code will >>need to be fixed itself anyways. >> >>It should be noted that $_APPLICATION will not be affected during >>run-time by other scripts changes, i.e. if a.php changes >>$_APPLICATION['foo'] whilst b.php is running, it doesn't see the changes >>till the next load... it might be nice to add a function to force a >>reload of data in the current file though? >> >>I'm not sure if you'd consider this to be implemented into the core, but >>perhaps you could implement it into a PECL extension and then it can be >>considered for core after it has had some real-life testing/scenarios >>thrown at it? >> >>Just to make it clear, I don't know C/C++ at all, this is just an idea >>that you might or might not like to implement, I cannot do it (I had >>help with the MD5 stuff ;). >> >>- Davey >> >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php