Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73476
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZzBchEyw14PkYoWW2dKJkiU6f6f1miGuHRMHEMPY4aqzQ@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>
 <CAGa2bXYutFpQFb+d3g3VT-zUutGYLVasBESkG+uyZTunWc6QCw@mail.gmail.com> <CAPhkiZzBchEyw14PkYoWW2dKJkiU6f6f1miGuHRMHEMPY4aqzQ@mail.gmail.com>
Date: Sat, 29 Mar 2014 10:09:14 +0900
Message-ID: <CAGa2bXZpUrW8Vw7Lm1PCMsSqZ2K150fRsejOtmbUhtaCV+6iew@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=089e0160be54e8682c04f5b47950
Subject: Re: [PHP-DEV] [RFC] session_start(), read_only, lazy_write; Take 2
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0160be54e8682c04f5b47950
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Sat, Mar 29, 2014 at 8:41 AM, Andrey Andreev <narf@devilix.net> wrote:

> You yourself told me that there's no way for the SessionHandler class
> to know if the storage module supports PS_UPDATE_TIMESTAMP_FUNC() or
> not, and that because of that we can't have
> SessionHandler::updateTimestamp().
>

It's only applicable for object based user save handler.
Since user is implemented their own handler, this limitation should not
matter.


>
> > Writing data and updating time stamp for GC is distinct feature.
>
> For file-based sessions - it is, but for i.e. a database, there's not
> much difference. write() does update the timestamp, I see no reason
> why it shouldn't be able to update just the timestamp.
>

How to update time stamp is up to save handler and its storage.
Write and updating time stamp is different operation.
Memcache does not need it if data is read. RDBMS may have separate
table to keep track time stamp. For PostgreSQL, updating one field is
faster than updating whole record.



>
> > I don't see good reason not to have API for it.
>
>  - Not being able to call parent::updateTimestamp() is a good reason.
>  - Having the completely unnecessary SessionUpdateTimestampInterface
> is a good reason.
>  - Breaking the design of current userland implementations is a good
> reason.
>  - Not being able to have lazy_write (a performance improvement, I
> remind you) by default is a good reason.
>

I think current design of object based save handler is better to be
redesigned.

Current object based save handler registers "previous" save handler as its
base.
However, it's mostly useless without calling parent open() function. i.e.
Other
calls simply fails when it does not.

When open() is called, some resource, e.g. file handle, db connection, etc,
is
opened. These resources cannot be accessed from user land, since it's not
"PHP resource", but raw resource. Thus it's only useful for file based
storage.
If user is using their own file based storage for some reason, they are
better
to implement their own handler fully.

I would like to remove and clean up this in future release.


>
> >> > 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.
>
> Convenience and consistency in the userland APIs is more important
> than "breaking" internal design. I understand you want to stick to
> best practices, but those practices are not a religion and sometimes
> you need to break them. If you ask me, a lot of things in ext/session
> are broken by design ... creating files from inside read() is one
> example, all methods exposed to userland to be in an interface is
> another. I agree, it's not perfect, but that's just what happens when
> we introduce new features into something that was never designed with
> possible changes in the future in mind. For PHP6, we'll have the
> freedom to redesign the whole thing completely, but for the time being
> - userland code is more important than not having some dependancy in
> write().
>

It's better to stick to cleaner code. Clean code is worth to have.
As I mentioned in previous, current object based save handler design has
very
limited usage and base class part would be better to be removed in the
future.
(It's not documented also :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0160be54e8682c04f5b47950--