> 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
> 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_MD5Update(&context, 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