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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
