Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions

From: Date: Mon, 17 Mar 2014 09:31:27 +0000
Subject: Re: [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Andrey,

On Mon, Mar 17, 2014 at 6:14 PM, Andrey Andreev <[email protected]> wrote:

> See, that's where it gets tricky ...
>
> Is there a SessionHandlerInterface::update() method? (I assume not,
> otherwise it would be enforced)
>

Session module handles interface a little different way.
There is create_sid() method for a long time, but it's not forced to be
implemented. validateSid() and update() method is the same as create_sid().

 Is there a default SessionHandler::update() method? If yes, how is
> that handled? That's supposedly just exposing the internal API and a
> user can choose whether to override one or many methods. But if all of
> them are overriden, how do you know it uses the same storage at all?
> And what if an existing userland handler already has an update()
> method that does something completely different?
>

There is dummy function for validateSid() and update().
Both returns true always.

If save handler (regardless of user or C) does not implement its own
update(),
then update() will not be called, instead write() is called.
To do that, address of the dummy function is compared.

 The devil is in the details and these details aren't explained
> anywhere, that's why I'm concerned.
>

Currently implemented save handlers work as it is now both user and C.

 Btw, this should probably be called updateTimestamp() instead of
> update(), for userland at least. write() vs. update() can be somewhat
> confusing.
>

This could be changed. Better name is always good.

Regards,

--
Yasuo Ohgaki
[email protected]


Thread (34 messages)

« previous php.internals (#73207) next »