Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73473
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZw9Agv=OnnSzsTNz+YwwrnMgdq7c2GY1U_Q6rcL2w6o5Q@mail.gmail.com>
References: <CAPhkiZyFHshFc56UEHiDFK9k801ztno+xoS82Yf6qAcwiRPg1A@mail.gmail.com>
 <010e01cf4788$05f3c5a0$11db50e0$@devtemple.com> <CAPhkiZx8DuDPfks-RNNNunHsjso-9KuwRBor8TjRaK3E10qUiA@mail.gmail.com>
 <01c801cf47c0$59acbf20$0d063d60$@devtemple.com> <CAPhkiZwNywUi_LjOcTmB_aDONHcmpHFtExW6h+S4yYHf4ypitQ@mail.gmail.com>
 <CAPhkiZwPBoN+Y+gyTXZB68HTfYkA5eZ-yn_=2FMvir+oFza5TQ@mail.gmail.com>
 <CAMUwpuRH-cQ9fasUyOft5C7JRi5N=6szwDV5inf+wNi-eAC2iA@mail.gmail.com>
 <CAPhkiZwLk4Kjh732WAkEF+U6VyMVEz5fzi4SNVhaQK9-Rdbnew@mail.gmail.com>
 <CAGa2bXYpS6HA2LHd3C8BQ+OK0nsDYEwCfF=K7_-A0tWeOqp3vA@mail.gmail.com>
 <CAPhkiZyWJ_602JzpP9p-3T_ABPDvENE=VriK8RSLPqNNw=zUWw@mail.gmail.com>
 <CAGa2bXbHCkFNx1U0e+Cuv7ixPonRZBmnXwvU8WUgu=Z=R=YMsA@mail.gmail.com>
 <CAPhkiZwnugyOWWsPghQY0L+Q_VMuwf1vHnjuZyAGUe7=Mox-ng@mail.gmail.com>
 <CAGa2bXYEpQENja0W2FbfU_NkUJ-sJsXJY_0Xb4NFmHyo7r9qug@mail.gmail.com> <CAPhkiZw9Agv=OnnSzsTNz+YwwrnMgdq7c2GY1U_Q6rcL2w6o5Q@mail.gmail.com>
Date: Sat, 29 Mar 2014 07:02:46 +0900
Message-ID: <CAGa2bXYutFpQFb+d3g3VT-zUutGYLVasBESkG+uyZTunWc6QCw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Julien Pauli <jpauli@php.net>, Bill Salak <bill@devtemple.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3f0200857c704f5b1df1e
Subject: Re: [PHP-DEV] [RFC] session_start(), read_only, lazy_write; Take 2
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3f0200857c704f5b1df1e
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Fri, Mar 28, 2014 at 7:50 PM, Andrey Andreev <narf@devilix.net> wrote:

> >> I still don't get it ... the session manager has to call either
> >> write() or updateTimestamp() and both of these are part of the session
> >> handler. Merging them into one solves the API design and BC issues, I
> >> don't see how it breaks any principle. They can still be split to two
> >> methods in PHP6, but for the time being, using write() for both
> >> purposes IMO solves way more problems than sticking to this design
> >> principle you're talking about.
> >
> >
> > Without API, manager cannot manage how it behaves. In general, submodule
> > should
> > avoid manager state dependency in general. It should have dedicated API
> for
> > each
> > distinct task rather than leaving it to managed by submodule. In
> addition,
> > manager
> > cannot know if save handler supports API or not. If there is API, I can
> > display save
> > handler capability in phpinfo() page, for example.
> >
> > If manager expects sub module to behave in some way, it should have
> explicit
> > API
> > for each feature. Otherwise, sub module implementation may differ module
> by
> > module.
> > Defined set of feature is better to have explicit API with modular
> design.
> > It's not mandatory,
> > but the best practice. I don't see reason not to follow the practice
> here.
>
> I agree in general, but you just gave a good reason not to follow that
> practice - you can't know if the submodule supports it. Plus, both are
> write operations with one of them just writing more data. I'm all for
> best practices, but in this case there's a lot of sense not to do
> everything by the book.
>

If there is API, sub module capability can be detected.

Writing data and updating time stamp for GC is distinct feature.
I don't see good reason not to have API for it.


>
> > Besides modular design, if write() and updateTimestamp() are merged, flag
> > parameter
> > for write() should be added. It breaks compatibility with current save
> > handlers. I don't
> > want BC that could be avoided also.
>
> No it shouldn't, the decision whether to write or just update the
> timestamp is based on an internal flag, or on $session_data. No
> additional parameters are required.


I removed PS(id) dependency from s_read() with new patch as planned. Why
should I introduce new dependency to s_write(), i.e. sub module, that
breaks
design?  It does not make sense.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3f0200857c704f5b1df1e--