I noticed something which you said, and forgive me if this part may be obvious, but you mentioned across instances of applications? Do you mean something like a shared memory between all web connections to the server? One issue I could forsee if this is the case, what happens when there is no connections to the server for an extended period of time (extended being even as short as a few minutes)? Should PHP store this superglobal's value indefinitely, or perform some type of garbage collection? If PHP should clean up after itself, what criteria would you expect to be followed for deciding if something is no longer useful? I don't think you would want this criteria configurable in a ini setting for example, because hosting companies all do something different. If a developer were to use this feature, they would need a standardized timeframe that the values would last. This is just a couple things I think would need to be considered before implementing something like this. If I am way out in left field, I apologize.
-Jeremy -----Original Message----- From: Davey [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 8:15 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables 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=b4a4ab7142b7d3209c7eee976912 0cba > &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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
