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

Hi, On Mon, Mar 17, 2014 at 11:02 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi Andrey, > > On Mon, Mar 17, 2014 at 5:52 PM, Andrey Andreev <narf@devilix.net> wrote: >> >> > It updates time stamp always. >> > >> > It does >> > >> > "write data if data is updated" >> > or >> > "write data if save handler does not have update API" >> > or >> > "update time stamp if it is needed" (e.g. memcache does not need to >> > update >> > time stamp since it updates time stamp by read. It's save handler >> > implementation choice what to do with update API) >> > >> > For save handlers like memcahe/memcached, session module is writing back >> > the >> > same data just to waste resources when session data hasn't changed. >> >> And what about userland session handlers? > > > It's the same as C written module. Unless there is update() method, session > module > writes session data always. See, that's where it gets tricky ... Is there a SessionHandlerInterface::update() method? (I assume not, otherwise it would be enforced) 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? The devil is in the details and these details aren't explained anywhere, that's why I'm concerned. Btw, this should probably be called updateTimestamp() instead of update(), for userland at least. write() vs. update() can be somewhat confusing. Cheers, Andrey.