Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73207
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZzmzTqPR4KynBCWijvHa=TGKzTni7JdfuuKdy_i=sBeQg@mail.gmail.com>
References: <CAPhkiZw5xWRkc=ofh-nB5ZkjfThZFkH_+pK5RZaQFLKhno7u7A@mail.gmail.com>
 <CAGa2bXZiBuw_L_ehvTZb5_UUedtbS0n4GXYUjtKix0S9DX_8KQ@mail.gmail.com>
 <5324FE40.1070704@sugarcrm.com> <CAPhkiZy1oG_WHijMknB34dyo0aZRDU89EBafpaEGqGM32DCK0A@mail.gmail.com>
 <532603A0.8060802@sugarcrm.com> <CAPhkiZxdrxiKT3cTW9ra=0aFDKKP3-OpjmGdxqzHxu8YEUK2ww@mail.gmail.com>
 <CAGa2bXbH8WFp=8C-ON-1aAHLiyTsemVKMH+dGnqBSJAw5zw-GA@mail.gmail.com>
 <CAPhkiZx52CiKkk385itjEtg99ox3PHzXga9ZWDPbWiB2wRyH4g@mail.gmail.com>
 <CAGa2bXZGun=khdMZHzYoERap7qj7bQDPEfQzx2jJ2MwPs7-p_g@mail.gmail.com> <CAPhkiZzmzTqPR4KynBCWijvHa=TGKzTni7JdfuuKdy_i=sBeQg@mail.gmail.com>
Date: Mon, 17 Mar 2014 18:31:27 +0900
Message-ID: <CAGa2bXb6k8NYyYheCM6dvFWj-jA2GLP7ZiusTgZK-YgkNkeHhQ@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1137ef8eda566904f4ca178b
Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about
 read_only, lazy_write sessions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1137ef8eda566904f4ca178b
Content-Type: text/plain; charset=UTF-8

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().

 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
yohgaki@ohgaki.net

--001a1137ef8eda566904f4ca178b--