# php feature - Thread: https://externals.io/message/28736 - Original archive: https://news-web.php.net/php.internals/28736 - Started by Oliver Block on 2007-04-11T23:29:31+00:00 - Messages: 15 - 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 --- ## #28736 — Oliver Block — 2007-04-11T23:29:31+00:00 URL: https://externals.io/message/28736#28736 Hello, did you ever discuss a feature like 'application variables'? What I mean is that a bunch of scripts builds a logic application which is e.g. able to share variables. While session variables can be used to store values between script files for a single user , 'application variables' store values within the whole application and not only for a single user. Regards, Oliver --- ## #28737 — Jarismar Chaves da Silva — 2007-04-11T23:42:31+00:00 URL: https://externals.io/message/28736#28737 · In reply to: #28736 I believe you can easily address this by using some non-volatile, application wide storage, like file system, or cookies. You can also implement a session handler and define some logic to load and save values from session in a transparent way. Oliver Block wrote: > Hello, > > did you ever discuss a feature like 'application variables'? What I mean is that a bunch of scripts builds a logic application which is e.g. able to share variables. While session variables can be used to store values between script files for a single user , 'application variables' store values within the whole application and not only for a single user. > > Regards, > > Oliver > > -- **Jarismar Chaves da Silva*** **ADP****Labs** *+55 51 3327 1491 jarismar_silva@adplabs.com.br http://www.adplabs.com.br This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. --- ## #28738 — Andrey Hristov — 2007-04-11T23:58:48+00:00 URL: https://externals.io/message/28736#28738 · In reply to: #28736 Oliver Block wrote: > Hello, > > did you ever discuss a feature like 'application variables'? What I mean is that a bunch of scripts builds a logic application which is e.g. able to share variables. While session variables can be used to store values between script files for a single user , 'application variables' store values within the whole application and not only for a single user. yes, you can use APC till some implements _APP and it gets accepted. > > Regards, > > Oliver > Andrey --- ## #28739 — Richard Lynch — 2007-04-12T00:34:48+00:00 URL: https://externals.io/message/28736#28739 · In reply to: #28736 > did you ever discuss a feature like 'application variables'? What I > mean is that a bunch of scripts builds a logic application which is > e.g. able to share variables. While session variables can be used to > store values between script files for a single user , 'application > variables' store values within the whole application and not only for > a single user. This has been discussed innumerable times since PHP 3.0 release candidate days, if not longer. There are several solutions already posted here, as well as at least two shared memory solutions, MCache, MemCache, and more. Having it built-in to PHP by default would have several issues. The overhead of maintaining APP variables is probably non-trivial, though you are welcome to submit a patch if you have a clean/simple/inexpensive solution. It also violates a basic premise of PHP from Day One as a "shared nothing" architecture where scaling is easily accomplished by throwing more hardware into a cluster/farm. Finally, shared data inevitably brings its own class of problems. Locking, stale data, replication, etc all have to be solved sooner or later, in some fashion, once you decide to go down this route. Many PHP Developers are simply not willing to pay these tolls for a feature that probably won't work well out of the box for large-scale applications, and isn't any better, for any given need, than one of the existing solutions. So if you actally need shared data for a project, go to PHP-General and describe your need/project, and see what folks recommend. If you think PHP should have shared data just because other languages have it, well, no, it shouldn't do that, for the reasons above (and probably more, which are beyind my ken) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #28740 — Andrew Hutchings — 2007-04-12T04:34:54+00:00 URL: https://externals.io/message/28736#28740 · In reply to: #28736 Oliver Block wrote: > Hello, > > did you ever discuss a feature like 'application variables'? What I mean is that a bunch of scripts builds a logic application which is e.g. able to share variables. While session variables can be used to store values between script files for a single user , 'application variables' store values within the whole application and not only for a single user. Isn't that what a database is for (e.g. MySQL)? Regards Andrew -- Andrew Hutchings - Linux Jedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you. --- ## #28742 — Adam Banko — 2007-04-12T08:01:29+00:00 URL: https://externals.io/message/28736#28742 · In reply to: #28736 Hi, I use ORM for sharing data between application processes. I think it fits well this use case. I think some well-defined, community-wide interface would be more beneficial than any implementation. If PECL, PEAR, and other extensions could implement this interface then the user could freely choose any storage method without loosing focus of the higher level task. It would also help migrations from one storage to another. Adam 2007. 04. 12, csütörtök keltezéssel 01.29-kor Oliver Block ezt írta: > Hello, > > did you ever discuss a feature like 'application variables'? What I mean is that a bunch of scripts builds a logic application which is e.g. able to share variables. While session variables can be used to store values between script files for a single user , 'application variables' store values within the whole application and not only for a single user. > > Regards, > > Oliver --- ## #28743 — Oliver Block — 2007-04-12T12:57:45+00:00 URL: https://externals.io/message/28736#28743 · In reply to: #28739 Am Donnerstag, 12. April 2007 02:34 schrieb Richard Lynch: > So if you actally need shared data for a project, go to PHP-General > and describe your need/project, and see what folks recommend. No, I don't. I was interested to know if it has been discussed and what the rationale was. Thanks for your summary. Yes, I had the idea while I was writing some scripts.:) Best Regards, Oliver --- ## #28747 — Oliver Block — 2007-04-12T14:38:01+00:00 URL: https://externals.io/message/28736#28747 · In reply to: #28740 Am Donnerstag, 12. April 2007 06:34 schrieb Andrew Hutchings: > Isn't that what a database is for (e.g. MySQL)? No. - It's that what a symbol table is for.:-) Best Regards, Oliver --- ## #28773 — Tijnema ! — 2007-04-13T06:56:15+00:00 URL: https://externals.io/message/28736#28773 · In reply to: #28747 > Am Donnerstag, 12. April 2007 06:34 schrieb Andrew Hutchings: > > […] > > No. - It's that what a symbol table is for.:-) > > Best Regards, > > Oliver You simply could create a table with 2 columns 'key' and 'value', and so you could easily store both :) Tijnema --- ## #28775 — Andrew Hutchings — 2007-04-13T07:29:29+00:00 URL: https://externals.io/message/28736#28775 · In reply to: #28773 Tijnema ! wrote: > > > […] > > You simply could create a table with 2 columns 'key' and 'value', and > so you could easily store both :) > I can see where Oliver is coming from, it would be a lot quicker to do it that way. But I can imagine there would be problems making something like that work with all the different types of Apache workers, etc... without some kind of separate daemon handling it. Regards Andrew -- Andrew Hutchings - Linux Jedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you. --- ## #28788 — Tijnema ! — 2007-04-13T13:46:56+00:00 URL: https://externals.io/message/28736#28788 · In reply to: #28775 > Tijnema ! wrote: > > […] > > I can see where Oliver is coming from, it would be a lot quicker to do > it that way. But I can imagine there would be problems making something > like that work with all the different types of Apache workers, etc... > without some kind of separate daemon handling it. > > Regards > Andrew I think that will screw up some things, for example when using 2 the same scripts, on the same apache, but on different locations. In current ways, the programmer would create a database, and use a separate table for both scripts. But if these "application variables" are there, the programmer would use those, but then script 1 & 2 would both share the same variables, and so that would give a lot of trouble. Especially because a lot people use shared hosting these days, and that means that they all run on the same apache. and so they would share the same "application variables". So if person a & b both install the same script on a different domain. They would work like 1 script, and that just goes wrong. Tijnema > -- > Andrew Hutchings - Linux Jedi - http://www.linuxjedi.co.uk/ > Windows is the path to the darkside...Windows leads to Blue Screen. Blue > Screen leads to downtime. Downtime leads to suffering...I sense much > Windows in you. --- ## #28794 — Andrew Hutchings — 2007-04-13T17:08:00+00:00 URL: https://externals.io/message/28736#28794 · In reply to: #28788 Tijnema ! wrote: > Especially because a lot people use shared hosting these days, and > that means that they all run on the same apache. and so they would > share the same "application variables". So if person a & b both > install the same script on a different domain. They would work like 1 > script, and that just goes wrong. Hmm...I could see this being a security risk as well, if one script is breached then you could get the variables PHP wide. Or something to that effect. Regards Andrew -- Andrew Hutchings - Linux Jedi - http://www.linuxjedi.co.uk/ Windows is the path to the darkside...Windows leads to Blue Screen. Blue Screen leads to downtime. Downtime leads to suffering...I sense much Windows in you. --- ## #28798 — Oliver Block — 2007-04-13T20:34:10+00:00 URL: https://externals.io/message/28736#28798 · In reply to: #28788 Am Freitag, 13. April 2007 15:46 schrieb Tijnema !: > I think that will screw up some things, for example when using 2 the > same scripts, on the same apache, but on different locations. It does not screw up things with session variables. The difference between session variables and application variables (I would say) is the scope. (Both are persistent between several requests.) There are ways to assure that requests are served by the same machine if sessions are used (load balancers). There is also the way to set up a central storage like you already can do with `session_set_save_handler()`. > Especially because a lot people use shared hosting these days, and > that means that they all run on the same apache. and so they would > share the same "application variables". So if person a & b both > install the same script on a different domain. They would work like 1 > script, and that just goes wrong. We two obviously have a different concept of application variable. As I understand it, you would never share applications variables between different domains (without the php programmer knowing that). But you are right, if you i.e. run a web application on a shared host, you could have a single directory served by several different subdomains, e.g. webapp.mydomain1.com, webapp.mydomain2.com, webapp.mydomain3.com with all domains mapped to the directory htdocs/webapp. But the programmer of the applicaton would have to consider this, not php. But as I said earlier, I was more interested in knowing the rationale why this feature hasn't been integrated yet, than in demanding it.:) (Right now I have no patch, either.) Best Regards, Oliver --- ## #28801 — Tijnema ! — 2007-04-13T21:35:21+00:00 URL: https://externals.io/message/28736#28801 · In reply to: #28798 > Am Freitag, 13. April 2007 15:46 schrieb Tijnema !: > > […] > > It does not screw up things with session variables. The difference between > session variables and application variables (I would say) is the scope. (Both > are persistent between several requests.) There are ways to assure that > requests are served by the same machine if sessions are used (load > balancers). There is also the way to set up a central storage like you > already can do with `session_set_save_handler()`. > > > […] > > We two obviously have a different concept of application variable. As I > understand it, you would never share applications variables between different > domains (without the php programmer knowing that). But you are right, if you > i.e. run a web application on a shared host, you could have a single > directory served by several different subdomains, e.g. webapp.mydomain1.com, > webapp.mydomain2.com, webapp.mydomain3.com with all domains mapped to the > directory htdocs/webapp. But the programmer of the applicaton would have to > consider this, not php. But once it is available. "stupid" PHP programmers are gonna use it, and distribute code using it, and while someone else, who doesn't know anything about PHP, installs it twice on same host, it does give a lot trouble. > > But as I said earlier, I was more interested in knowing the rationale why this > feature hasn't been integrated yet, than in demanding it.:) (Right now I have > no patch, either.) > > Best Regards, > > Oliver > I think it would only give more trouble... and like noted before, it's a lot of work to integrate it in all apache workers... (not to mention PHP as CGI...) Tijnema --- ## #28802 — Richard Lynch — 2007-04-13T21:35:32+00:00 URL: https://externals.io/message/28736#28802 · In reply to: #28794 > > […] > > Hmm...I could see this being a security risk as well, if one script is > breached then you could get the variables PHP wide. Or something to > that effect. For all these reasons, and more, you're really better off just using the right weapon for YOUR needs than having something kinda sorta maybe that might work for you from the PHP Dev Team. Whether your needs dictate a DB, LDAP, MCache, MemCache, NFS files, SysV shared memory, custom daemon, or trained squirrels is up to you. This is why PHP doesn't have shared APP variables in the first place -- It's just a Bad Idea once you really think through all the implications. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?