Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <50653.216.230.84.67.1176338088.squirrel@www.l-i-e.com>
In-Reply-To: <200704112329.l3BNTVnK000581@post.webmailer.de>
References:  <200704112329.l3BNTVnK000581@post.webmailer.de>
Date: Wed, 11 Apr 2007 19:34:48 -0500 (CDT)
To: "Oliver Block" <lists@block-online.eu>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] php feature
From: ceo@l-i-e.com ("Richard Lynch")

On Wed, April 11, 2007 6:29 pm, Oliver Block wrote:
> 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?