# [Proposal] Idea for Application level variables - Thread: https://externals.io/message/3795 - Original archive: https://news-web.php.net/php.internals/3795 - Started by Davey on 2003-08-07T12:36:46+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #3795 — Davey — 2003-08-07T12:36:46+00:00 URL: https://externals.io/message/3795#3795 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 --- ## #3796 — Andrey Hristov — 2003-08-07T12:55:43+00:00 URL: https://externals.io/message/3795#3796 · In reply to: #3795 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 --- ## #3797 — Davey — 2003-08-07T13:15:12+00:00 URL: https://externals.io/message/3795#3797 · In reply to: #3796 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 > > > > > […] --- ## #3798 — Stefan Walk — 2003-08-07T13:19:28+00:00 URL: https://externals.io/message/3795#3798 · In reply to: #3797 > Andrey, > 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 Check out this one: http://www.turcksoft.com/en/e_mmc.htm#api -- Regards, Stefan Walk > > > […] > > > Check out this one: > http://www.turcksoft.com/en/e_mmc.htm#api MMCache can be used as a session handler, but this still has the pitfalls of the other solutions. If you were to implement $_APP(LICATION) as suggested, then it could indeed (in theory) use MMCache, just as $_SESSION does - Davey --- ## #3800 — Wojtek Meler — 2003-08-07T13:50:41+00:00 URL: https://externals.io/message/3795#3800 · In reply to: #3799 Davey wrote: > MMCache can be used as a session handler, but this still has the > pitfalls of the other solutions. > > If you were to implement $_APP(LICATION) as suggested, then it could > indeed (in theory) use MMCache, just as $_SESSION does > > - Davey As far as I understand you just want to have another superglobal variable, don't you? If so I have small patch witch allow to configure in php.ini names for additional superglobals. Regards, Wojtek --- ## #3801 — Davey — 2003-08-07T14:17:06+00:00 URL: https://externals.io/message/3795#3801 · In reply to: #3800 Wojtek Meler wrote: > Davey wrote: > > > […] > > > As far as I understand you just want to have another superglobal > variable, don't you? > If so I have small patch witch allow to configure in php.ini names for > additional superglobals. > > Regards, > Wojtek > Well, whilst this could work, it means that $_APP(LICATION) would not have the same infrastrcture below it as $_SESSION does (automatic serializing/unserializing and the ability to switch the data storage from files, to user, to SQLite and to MMCache) - Davey P.S. Would mind that patch anyways, sounds good, just doesn't fulfill my needs/desires for $_APP(LICATION) --- ## #3803 — Justin Hannus — 2003-08-07T16:18:08+00:00 URL: https://externals.io/message/3795#3803 · In reply to: #3801 So it seems like to get the same functionality, in userland, why not just: $_APPLICATION = &$_SESSION -Justin "Davey" wrote in message news:20030807141706.32237.qmail@pb1.pair.com... > Wojtek Meler wrote: > > […] > > Well, whilst this could work, it means that $_APP(LICATION) would not > have the same infrastrcture below it as $_SESSION does (automatic > serializing/unserializing and the ability to switch the data storage > from files, to user, to SQLite and to MMCache) > > - Davey > > P.S. > > Would mind that patch anyways, sounds good, just doesn't fulfill my > needs/desires for $_APP(LICATION) --- ## #3802 — Alan Richmond — 2003-08-07T16:25:28+00:00 URL: https://externals.io/message/3795#3802 · In reply to: #3795 ] Subject: [PHP-DEV] [Proposal] Idea for Application level variables I would love to see an application level superglobal. It's the one thing I miss about ColdFusion. Like with CF's shared-scope variables, locking will be key, to avoid corruption. (Reading while being written to.) I'm currently using PEAR Cache_Lite with a named group to emulate but it lacks ease of use. -Alan --- ## #3806 — Andrey Hristov — 2003-08-07T16:34:57+00:00 URL: https://externals.io/message/3795#3806 · In reply to: #3803 Nope, the data should be shared amongst all running processes of the application disregarding the web user who invokes them. Andrey ----- Original Message ----- From: "Justin Hannus" To: Sent: Thursday, August 07, 2003 7:18 PM Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables > So it seems like to get the same functionality, in userland, why not just: > > $_APPLICATION = &$_SESSION > > -Justin > > "Davey" wrote in message > news:20030807141706.32237.qmail@pb1.pair.com... > > […] --- ## #3810 — Ilia Alshanetsky — 2003-08-07T17:06:25+00:00 URL: https://externals.io/message/3795#3810 · In reply to: #3801 It seems to be that what we're looking for is a simple wrapper around sysvshm or shmop (we want win32 support?) that would create $_APP superglobal and store data within that superglobal. The only issue would be that shm segment cannot be easily resized and on many systems there is an upper limit on the shm segment size. Which means you'd probably need to use a file backed shm implementation such as anonymous mmap. This however means that you cannot use shmop or sysvshm, however something like mmcache previously mentioned should be a fine solution. All you'd need to do is make a wrapper around $_SESSION. Ilia > Wojtek Meler wrote: > > […] > > Well, whilst this could work, it means that $_APP(LICATION) would not > have the same infrastrcture below it as $_SESSION does (automatic > serializing/unserializing and the ability to switch the data storage > from files, to user, to SQLite and to MMCache) > > - Davey > > P.S. > > Would mind that patch anyways, sounds good, just doesn't fulfill my > needs/desires for $_APP(LICATION) --- ## #3804 — Ken Tossell — 2003-08-07T17:25:52+00:00 URL: https://externals.io/message/3795#3804 · In reply to: #3803 Justin Hannus wrote: >So it seems like to get the same functionality, in userland, why not just: > >$_APPLICATION = &$_SESSION > > Or if (!isSet($_SESSION['myApplication'])) { $_SESSION['myApplication'] = array(); } $_APPLICATION =& $_SESSION['myApplication']; >-Justin > >"Davey" wrote in message >news:20030807141706.32237.qmail@pb1.pair.com... > > > > […] --- ## #3813 — Davey — 2003-08-07T20:31:47+00:00 URL: https://externals.io/message/3795#3813 · In reply to: #3803 Justin Hannus wrote: > So it seems like to get the same functionality, in userland, why not just: > > $_APPLICATION = &$_SESSION > > -Justin Uh... then its still only on a session basis. - Davey > "Davey" wrote in message > news:20030807141706.32237.qmail@pb1.pair.com... > > > […] --- ## #3814 — Davey — 2003-08-07T20:35:07+00:00 URL: https://externals.io/message/3795#3814 · In reply to: #3810 Ilia Alshanetsky wrote: > It seems to be that what we're looking for is a simple wrapper around sysvshm > or shmop (we want win32 support?) that would create $_APP superglobal and > store data within that superglobal. The only issue would be that shm segment > cannot be easily resized and on many systems there is an upper limit on the > shm segment size. Which means you'd probably need to use a file backed shm > implementation such as anonymous mmap. This however means that you cannot use > shmop or sysvshm, however something like mmcache previously mentioned should > be a fine solution. All you'd need to do is make a wrapper around $_SESSION. > > Ilia You've hit the nail on the head! By literally copying and pasting the $_SESSION code over, s/_SESSION/_APPLICATION and forcing the SID to be a certain thing, you pretty much implement what I want. The reasons you cannot just wrap $_SESSION and force a SESSION SID is if you want SESSION vars *and* APPLICATION vars in the same script, you'll run into problems... cause you cannot run simulatenous sessions and you certainly cannot switch when you write to a different var. - Davey --- ## #3817 — Davey — 2003-08-07T20:52:23+00:00 URL: https://externals.io/message/3795#3817 · In reply to: #3816 Ilia Alshanetsky wrote: > > > > […] > > > I do not believe that such a functionality is required in the core of PHP. > This maybe a very useful PECL extension if you are willing to write it. > However, I'd consider using existing utilities like SRM, which does not seem > to be so much of an overkill. > > Ilia I agree this is perhaps not something required in the core, however, I think once it is released as a PECL package, its inclusion into the core should at least be evaluated :) As I mentioned before, my C/C++ knowledge is null and void, so I am merely making the suggestions from an end user POV to see if anyone would be interested in implementing it... after the dust has settled here over the idea, it will probably be best to approach the PECL people (more) directly and ask someone to implement it. - Davey --- ## #3816 — Ilia Alshanetsky — 2003-08-07T20:54:36+00:00 URL: https://externals.io/message/3795#3816 · In reply to: #3814 > You've hit the nail on the head! By literally copying and pasting the > $_SESSION code over, s/_SESSION/_APPLICATION and forcing the SID to be a > certain thing, you pretty much implement what I want. The reasons you > cannot just wrap $_SESSION and force a SESSION SID is if you want > SESSION vars *and* APPLICATION vars in the same script, you'll run into > problems... cause you cannot run simulatenous sessions and you certainly > cannot switch when you write to a different var. I do not believe that such a functionality is required in the core of PHP. This maybe a very useful PECL extension if you are willing to write it. However, I'd consider using existing utilities like SRM, which does not seem to be so much of an overkill. Ilia --- ## #3823 — Tom Rogers — 2003-08-08T03:27:29+00:00 URL: https://externals.io/message/3795#3823 · In reply to: #3795 Hi, Thursday, August 7, 2003, 10:36:46 PM, you wrote: D> Hey, D> I'm quite new to this, so please don't shoot this down too harshly. If I D> don't explain something clearly enough, please ask me. D> Because Application variables are pretty much shared session variables, D> I wonder if perhaps the session code can be modified to handle these D> variables. D> In userland, the implementation would be similar to sessions, and can D> work on two levels, for a single file or for a group of files. D> Userland usage examples: D> // cross file (i.e. an entire website) D> application_vars_start('my_website'); // my_website is used as the SID D> $_APPLICATION['website_users'] += 1; D> // single file D> application_vars_start(); // uses filename based SID, see below D> $_APPLICATION['page_users'] += 1; D> I figured that by using the following in place of the user-input SID, D> you can easily have page-wide application vars, and by using the arg for D> application_var_start() in the the place of D> SG(request_info).path_translated you can have it across whatever you D> like, problem is when you have multiple sites on the same server, D> someone else might choose the same name D> PHP_MD5_CTX context; D> PHP_MD5Init(&context); D> PHP_MD5Update(&context, SG(request_info).path_translated, D> strlen(SG(request_info).path_translated)); D> PHP_MD5Final(key, &context); D> I don't know if this is clear enough, but in my head at least, it seems D> a inexpensive solution to something PHP is (in some peoples opinion) D> lacking. (Note: SRM seems like overkill just for this). D> Another nice thing about this, as it'll be using the Session D> infrastructure it could use the session handlers aswell (sqlite, mm etc) D> one problem that has been mentioned is multi-threaded situations, but I D> would assume that either the current session code doesn't suffer from D> this (and therefore neither will this) or that the session code will D> need to be fixed itself anyways. D> It should be noted that $_APPLICATION will not be affected during D> run-time by other scripts changes, i.e. if a.php changes D> $_APPLICATION['foo'] whilst b.php is running, it doesn't see the changes D> till the next load... it might be nice to add a function to force a D> reload of data in the current file though? D> I'm not sure if you'd consider this to be implemented into the core, but D> perhaps you could implement it into a PECL extension and then it can be D> considered for core after it has had some real-life testing/scenarios D> thrown at it? D> Just to make it clear, I don't know C/C++ at all, this is just an idea D> that you might or might not like to implement, I cannot do it (I had D> help with the MD5 stuff ;). D> - Davey Have you looked at msession, it can be setup to handle application wide variables. -- regards, Tom --- ## #3824 — Wojtek Meler — 2003-08-08T05:53:35+00:00 URL: https://externals.io/message/3795#3824 · In reply to: #3801 Davey wrote: > Would mind that patch anyways, sounds good, just doesn't fulfill my > needs/desires for $_APP(LICATION) You can find it on http://strony.wp.pl/wp/wmeler/ (auto_globals.patch) Regards, Wojtek