[Proposal] Idea for Application level variables View as Markdown

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:

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" davey@php.net
To: internals@lists.php.net
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

] 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

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