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

From: Date: Mon, 17 Mar 2014 09:57:54 +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 11  Groups: php.internals 
Request: Send a blank email to internals+get-73208@lists.php.net to get a copy of this message
Hi, On Mon, Mar 17, 2014 at 11:31 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Mon, Mar 17, 2014 at 6:14 PM, Andrey Andreev <narf@devilix.net> 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(). I believe I already replied to this previously ... *sid() is passed to the other functions, so that's not really relevant. But ok, I get the idea. >> 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. Ok, so why is 'lazy_write' an option at all then? I don't see a reason why it shouldn't be the default and even mandatory behavior. >> 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. Well, there you go - updateTimestamp() is a better name. ;) Cheers, Andrey.

« previous php.internals (#73208) next »