Re: Re: Revert session_serializer_name(), session_gc()
| From: | Yasuo Ohgaki | Date: | Sat, 15 Mar 2014 06:28:13 +0000 |
| Subject: | Re: Re: Revert session_serializer_name(), session_gc() | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-73176@lists.php.net to get a copy of this message | ||
On Sat, Mar 15, 2014 at 2:10 PM, Andrey Andreev <narf@devilix.net> wrote:
> On Sat, Mar 15, 2014 at 6:36 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi all,
> >
> > On Sat, Mar 15, 2014 at 1:15 PM, Yasuo Ohgaki <yohgaki@ohgaki.net>
> wrote:
> >>>
> >>>
> >>> Now back to the main topic:
> >>>
> >>> Please exclude session_serializer_name(), session_gc(),
> >>> session_reset(), session_abort() and the "session write short-circuit"
> >>> from the 5.6 branch.
> >>
> >>
> >> I removed session_serializer_name() and session_gc()
> >> (Although session_gc() is mandatory API, IMO)
> >> I like the idea removing INI modifying function in the future release.
> >>
> >> I don't understand reason why you insist removal of session_reset()
> >> and session_abort(). They are just missing API for session module,
> >> like session_gc().
> >>
> >> There should be API (i.e. function/method or parameters) for distinct
> >> operations that user may use.
> >>
> >> I may agree if you could provide the reason why there should not be
> >> these APIs.
>
> session_abort(), session_reset() are just two functions that somebody
> asked about in 2002 via bugs.php.net and nobody responded (11 years
> without a single comment) right up until you just assumed it's a good
> idea and commited it. If it was "missing API", surely at least 1 user
> per year would've requested it. ;)
>
> I understand that you see them as small, trivial additions, but being
> a part of sessions automatically makes them very important and as
> such, they should be evaluated collectively, not by a single person.
>
It does not explain why it is not needed.
For example, session_abort() can be used to with error/exception during
execution.
You may not use, but I would use it to make sure $_SESSION would not
contains
any unneeded changes when error/exception occurred.
> I thought it might be better to explain what new functions do.
> >
> > session_gc() executes GC without tweaking INIs.
> > session_abort() aborts session without writing $_SESSION. There is no way
> > achieve w/o it.
> > session_reset() re-reads session and re-initializes $_SESSION. There is
> no
> > way achieve w/o it. (It could be done with session_abort(), though)
> > "write short circuit" omits "write" when $_SESSION hasn't change.
> > There
> is
> > no point calling write API and writing to storage for the same data.
>
> "write short circuit" as I understand it, is an exact copy of the
> 'lazy_write' option. This will be addressed in the previously
> mentioned RFC that I'll post later today.
No. It's not.
"lazy_write" does not lock session data while "write short circuit" does.
In other words, "lazy_write" changes session behavior, but "write short
circuit" does not.
i.e. With locked session data, "write short circuit" would not change how
session manager works.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net