Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73280
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZz_dQLP-J2Z7iS+yrFWc8DmejSGRkVUEyfq9qsgCkmcuw@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>
 <CAGa2bXb6k8NYyYheCM6dvFWj-jA2GLP7ZiusTgZK-YgkNkeHhQ@mail.gmail.com>
 <CAPhkiZz-_PxvfsCiMDm8Hf9YzVNV+Ch1zpqDut19uV1w1WCWoA@mail.gmail.com>
 <CAGa2bXb45BizZ8g8zzdneV_27R7zgiX34xoZm+f8YyNQrZxdTQ@mail.gmail.com>
 <CAPhkiZxi0UxrrUMRNUFDmkzs2pX6y81PPabzLjLF-ChboaB8jg@mail.gmail.com>
 <CAGa2bXYajPoD6D34nPXvja-Xz+pc3bCwPi6f7U-5iA3=Z75h-w@mail.gmail.com>
 <5327DD6E.6030402@sugarcrm.com> <CAGa2bXZk1BhfM4Ze9_+XDpJshGeKi==sYTXJ=_76oCJr=r75SQ@mail.gmail.com>
 <CAPhkiZzE4PxOEzynQvCAquqtJ5Roajzb9GbHUb=a=rbxKTh+hA@mail.gmail.com>
 <CAGa2bXYP0dbB15q5z+_MfV4-XjCmWJTg11YxO-wC4hQCkq24BA@mail.gmail.com> <CAPhkiZz_dQLP-J2Z7iS+yrFWc8DmejSGRkVUEyfq9qsgCkmcuw@mail.gmail.com>
Date: Wed, 19 Mar 2014 08:50:40 +0900
Message-ID: <CAGa2bXYnvFz-MtH21+vg=3siAsK_uTndUNCptCkozW=OarGJ9A@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=14dae94edbd37d7e2a04f4ea3667
Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about
 read_only, lazy_write sessions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--14dae94edbd37d7e2a04f4ea3667
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Wed, Mar 19, 2014 at 8:27 AM, Andrey Andreev <narf@devilix.net> wrote:

> On Wed, Mar 19, 2014 at 1:04 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi all,
> >
> > On Tue, Mar 18, 2014 at 7:58 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >>
> >> Exacly why I wrote an RFC, except Yasuo already explained that current
> >> workflows (speaking of userland handlers) are not affected and BC is
> >> maintaned.
> >
> >
> > I found issue with object based save handlers, but it was solved without
> any
> > BC.
> >
> > I also added createSid() method support. If both create_sid() and
> > createSid() exists,
> > createSid() is used.
>
> I thought this was currently in discussion, and in a separate thread?
>
> >> > How about making it a INI option? It makes session_start() option
> >> > handling
> >> > code
> >> > a little simpler. It's not mandatory, though.
> >>
> >> +1 from me, if it is to be kept as an option.
> >
> >
> > I'm about to modify patch to make it INI. No objections for this?
>
> Well, I said 'if' we keep it as an option at all. I'd rather update
> the RFC to propose it as non-optional behavior since there are no
> downsides from it, as I understand.
>

How should we handle this?
It was session_start() option e.g. session_start(['lazy_write'=>true]);
We are proposing make it INI option.

Since session_start() accepts all INI options, so it can work as
session_start(['lazy_write'=>true]);
with INI.

Anyone?


>
> >> > I think we are better to have another SessionHandler object that
> support
> >> > new
> >> > APIs.
> >> > We can handle create_sid() method rename with new object also. We may
> >> > keep
> >> > current implementation undocumented and may document it new one
> >> > (createSid()) only.
> >> > I will name it "SessionUpdateTimestampHandler". If anyone has
> >> > suggestions,
> >> > I would appreciate it.
> >>
> >> I object, although it should've been called SessionFilesHandler in the
> >> first place, that way we could also have SessionMemcacheHandler,
> >> SessionWhateverHandler - way nicer than it currently is, but again -
> >> not the point of this discussion.
> >
> >
> > I removed new object. It's not needed anymore, since I prevented bogus
> > methods
> > registration.
>
> Bogus methods? I wrote this RFC because it was completely unclear how
> certain situations would be handled ... now this is also unclear. :)
> I sent you a private e-mail earlier today, perhaps you could explain
> me that in a reply to it so that we don't spam the list.


It works as it is now.
Please refer to code for details.

https://github.com/php/php-src/pull/628/

It's mostly done.

Anyway, object based save handler registers "previous save handler"
function as
base methods. It may call bogus method for user handler.

 - Previous save handler may not have new API
 - Calling base class method is invalid. i.e. Overriding open() etc.

I made new API optional completely. Therefore,  current save handler
works as it is now and users may define new API if they want.
Existing code (5.5 and less) has many protections against bogus method
calls, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--14dae94edbd37d7e2a04f4ea3667--