Davey wrote:
MMCache can be used as a session handler, but this still has the
pitfalls of the other solutions.
If you were to implement $_APP(LICATION) as suggested, then it could
indeed (in theory) use MMCache, just as $_SESSION does
- Davey
As far as I understand you just want to have anothe
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 applicati
So it seems like to get the same functionality, in userland, why not just:
$_APPLICATION = &$_SESSION
-Justin
"Davey" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Wojtek Meler wrote:
> > Davey wrote:
> >
> >> MMCache can be used as a session handler, but this still has the
> >>
P-DEV] [Proposal] Idea for Application level variables
So it seems like to get the same functionality, in userland, why not
just:
$_APPLICATION = &$_SESSION
-Justin
"Davey" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Wojtek Meler wrote:
> > Davey wrote:
On August 7, 2003 04:35 pm, Davey wrote:
> You've hit the nail on the head! By literally copying and pasting the
> $_SESSION code over, s/_SESSION/_APPLICATION and forcing the SID to be a
> certain thing, you pretty much implement what I want. The reasons you
> cannot just wrap $_SESSION and force
> From: Andrey Hristov [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 6:35 PM
> Nope,
> the data should be shared amongst all running processes of
> the application disregarding the web user who invokes them.
This may partly do what you need?
http://pwee.sourceforge.net/
never use
Wojtek Meler wrote:
Davey wrote:
MMCache can be used as a session handler, but this still has the
pitfalls of the other solutions.
If you were to implement $_APP(LICATION) as suggested, then it could
indeed (in theory) use MMCache, just as $_SESSION does
- Davey
As far as I understand you ju
The storage, just like $_SESSION can be any of the pre-defined settings
(mm, files or SQLite (php5)) or "user" and can then be stored in a
database or whatever system the user wants. (This would indeed mean that
an application_set_save_handler() will also need to be there)
I think that the $_A
Justin Hannus wrote:
So it seems like to get the same functionality, in userland, why not just:
$_APPLICATION = &$_SESSION
Or
if (!isSet($_SESSION['myApplication'])) {
$_SESSION['myApplication'] = array();
}
$_APPLICATION =& $_SESSION['myApplication'];
-Justin
"Davey" <[EMAIL PROTECTED]>
Ilia Alshanetsky wrote:
On August 7, 2003 04:35 pm, Davey wrote:
You've hit the nail on the head! By literally copying and pasting the
$_SESSION code over, s/_SESSION/_APPLICATION and forcing the SID to be a
certain thing, you pretty much implement what I want. The reasons you
cannot just wrap $_
] 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 current
It seems to be that what we're looking for is a simple wrapper around sysvshm
or shmop (we want win32 support?) that would create $_APP superglobal and
store data within that superglobal. The only issue would be that shm segment
cannot be easily resized and on many systems there is an upper limi
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 th
Stefan Walk wrote:
On Thu, Aug 07, 2003 at 02:15:12PM +0100, Davey wrote:
Andrey,
This isn't quite as transparent as $_SESSION is and $_APPLICATION would
also not be a superglobal. What I would like to see at the end of this
is a $_APPLICATION variable (or $_APP? some poeple complained that
$_
Subject: Re: [PHP-DEV] [Proposal] Idea for Application level variables
> So it seems like to get the same functionality, in userland, why not just:
>
> $_APPLICATION = &$_SESSION
>
> -Justin
>
> "Davey" <[EMAIL PROTECTED]> wrote in message
>
Davey wrote:
Would mind that patch anyways, sounds good, just doesn't fulfill my
needs/desires for $_APP(LICATION)
You can find it on http://strony.wp.pl/wp/wmeler/
(auto_globals.patch)
Regards,
Wojtek
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.ne
Ilia Alshanetsky wrote:
It seems to be that what we're looking for is a simple wrapper around sysvshm
or shmop (we want win32 support?) that would create $_APP superglobal and
store data within that superglobal. The only issue would be that shm segment
cannot be easily resized and on many syste
Andrey,
> // 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());
> $_APPLICAT
Justin Hannus wrote:
So it seems like to get the same functionality, in userland, why not just:
$_APPLICATION = &$_SESSION
-Justin
Uh... then its still only on a session basis.
- Davey
"Davey" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Wojtek Meler wrote:
Davey wrote:
MMCa
On Thu, Aug 07, 2003 at 02:15:12PM +0100, Davey wrote:
> Andrey,
> This isn't quite as transparent as $_SESSION is and $_APPLICATION would
> also not be a superglobal. What I would like to see at the end of this
> is a $_APPLICATION variable (or $_APP? some poeple complained that
> $_APPLICATION
20 matches
Mail list logo
