Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZTU5HzM4oXyiu0PnS=W2Oz1uLP_BnyWBUXyYUTO0tMYg@mail.gmail.com>
References: <CAPhkiZx=0Vr5p=7VZJD4PeD0ub-khSVMw3G03QhO8CC4xxm11A@mail.gmail.com>
	<CAGa2bXZTU5HzM4oXyiu0PnS=W2Oz1uLP_BnyWBUXyYUTO0tMYg@mail.gmail.com>
Date: Wed, 12 Mar 2014 01:54:21 +0200
Message-ID: <CAPhkiZz_d_wFPgwwYXJD-A+tz0Uf9KQ6uXNi1HhZGWFF1=W91A@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: Revert session_serializer_name(), session_gc()
From: narf@devilix.net (Andrey Andreev)

Hi Yasuo,

On Wed, Mar 12, 2014 at 12:37 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Andrey,
>
> On Tue, Mar 11, 2014 at 10:37 PM, Andrey Andreev <narf@devilix.net> wrote:
>>
>> I just saw this in the 5.6-alpha1 changelog:
>>
>>    - Implemented Request #54649 (Create session_serializer_name()).
>> (Yasuo)
>>     ...
>>    - Implemented Request #11100 (session_gc() function). (Yasuo)
>>
>>
>> I didn't find an RFC and I don't know a way to search for a discussion
>> on internals (Google doesn't find one).
>>
>> session_serializer_name(): https://bugs.php.net/bug.php?id=54649
>>
>> I don't think that this should've been implemented, especially with
>> the reasoning from the feature request ... The same could be applied
>> to all session ini options and especially now since session_start()
>> accepts them, it's useless IMO.
>>
>> session_gc() was added in a similar fashion:
>> https://bugs.php.net/bug.php?id=11100
>>
>> There's already a comment about how the same thing can be achieved by
>> overloading SessionHandler::gc(), but a user could also just alter
>> session.gc_divisor, session.gc_probability to ensure that the garbage
>> collector is started.
>
>
> Users want to have contorl *when* gc is performed rather than luck. This is
> reasonable. IMO.

I like control, it's nice and *I already have it*:

    ini_set('session.gc_probability', 1);
    ini_set('session.gc_divisor', 1);

>>
>> And while session_serializer_name() is just redundant, session_gc()
>> could cause performance issues.
>
> There is session_module_name(), why not session_serializer_name()?

Why not session_cookie_lifetime()?
Why not session_cache_limiter()?
Why not session_entropy_file()?
etc.

"Why not" is never a good argument in programming and really, when is
the last time that you've seen something accepted here on internals
because of "why not"?
I'd rather question if session_module_name() is useful, or any
function that's an alias for ini_set('something', ...).

> Many 3rd party save handler implements many serializer.

I haven't seen many. In fact, I've seen none.

> session_gc() is nothing to do with performance. Users may abuse. The same
> argument applies to gc probability.

The problem is, users WILL abuse and that's bad.
Think of what the manual page would say about that function. Something
in the lines of:

    Calls the session garbage collector, ignoring
session.gc_probablity and session.gc_divisor.

What does that say to an inexperienced and even to the intermediate
user, who doesn't even know what GC is?

    "Hey, this collects garbage! It's nice to clean things up, I
should always call it!"

Yet another bad practice spreads.
Sure, that *could* apply to gc_probability, gc_divisor, but those are
*necessary* options and they are not easy to find unless you are
specifically looking for them.

>
>> I'd strongly suggest that these 2 functions should be removed before
>> PHP 5.6 is officially released.
>
>
> These are simple additional APIs.
> If your argument applies, there should be number of new RFCs.

Actually, if my argument applies - both feature requests should've
been ignored. Lots of people make "this would be nice" feature
requests without having the knowledge and experience to know if it
would really be "nice". That's why there's a bunch of smart people
here to take the decisions for them, collectively. I myself have been
forced to write an RFC for a smaller and less impactful change, but
that's not the point. Both of these functions should've at least been
discussed here on internals.

And finally, do you assume that there's demand for these features?
session_gc() specifically was requested 13 YEARS ago and it didn't
even get a "+1" comment in that timeframe. There are people on this
list who'd question user demand even if people are tweeting about the
feature with fingers crossed that it would be implemented ... these
are two that hardly anybody cares about.

Cheers,
Andrey.