Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:3823
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 8 Aug 2003 13:27:29 +1000
Reply-To: Tom Rogers <trogers@kwikin.com>
Organization: Perfect Web Site Designs
Message-ID: <1982538420.20030808132729@kwikin.com>
To: Davey <davey@php.net>
CC: internals@lists.php.net
In-Reply-To: <20030807123647.61433.qmail@pb1.pair.com>
References: <20030807123647.61433.qmail@pb1.pair.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables
From: trogers@kwikin.com (Tom Rogers)

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