Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73278
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZzE4PxOEzynQvCAquqtJ5Roajzb9GbHUb=a=rbxKTh+hA@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>
Date: Wed, 19 Mar 2014 08:04:32 +0900
Message-ID: <CAGa2bXYP0dbB15q5z+_MfV4-XjCmWJTg11YxO-wC4hQCkq24BA@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=047d7beb97d88ae05c04f4e99161
Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about
 read_only, lazy_write sessions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--047d7beb97d88ae05c04f4e99161
Content-Type: text/plain; charset=UTF-8

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.

Since user does not have to user Session module defined interface, user may
omit create_sid() definition.

Even without createSid() or my patch, current behavior is some what
confusing.
I'll document  them all later.

> No problem.
> >
> > 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?


>
> > I found issue with object based user save handler. Unlike procedural user
> > save handlers,
> > object based user save handler uses previously used save handler as it's
> > base class (some what)
>
> Isn't that the whole point of it, that you can overload only specific
> parts of the default one?
>

It's solved. I should have try to prevent defining bogus handlers.
i.e. Existing C written save handlers do not support new API and object
based
save handler try to call it if user hasn't define method for these.


>
> > 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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--047d7beb97d88ae05c04f4e99161--