Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXY86ri7b=rquo8Vbbh5ZoHOkwGBRoPWPup-SVPMu0WEgg@mail.gmail.com>
References: <CAPhkiZx=0Vr5p=7VZJD4PeD0ub-khSVMw3G03QhO8CC4xxm11A@mail.gmail.com>
	<CAGa2bXZTU5HzM4oXyiu0PnS=W2Oz1uLP_BnyWBUXyYUTO0tMYg@mail.gmail.com>
	<CAPhkiZz_d_wFPgwwYXJD-A+tz0Uf9KQ6uXNi1HhZGWFF1=W91A@mail.gmail.com>
	<CAGa2bXY86ri7b=rquo8Vbbh5ZoHOkwGBRoPWPup-SVPMu0WEgg@mail.gmail.com>
Date: Wed, 12 Mar 2014 13:04:03 +0200
Message-ID: <CAPhkiZyEqcx+UTPzpyYjz9pxWJnCNDO9pUMQNxvTpnrxmez9nw@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,

On Wed, Mar 12, 2014 at 2:19 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Andrey,
>
> On Wed, Mar 12, 2014 at 8:54 AM, Andrey Andreev <narf@devilix.net> wrote:
>>
>> > 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);
>
>
> Of course you can.
> It does not look nice as API. API should have good name for it. IMO.
>
> session_gc() is useful for both low traffic site and high traffic site.
> I don't see reason not to have explicit gc API. User may simply call
>
> session_gc();
>
> periodically by cron, etc.

There's a very good reason not to have it, you just ignored most of my
previous email which explained exactly that.

>> >> 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.
>
>
> Those aren't changed by programs often.

Oh, trust me - cookie lifetime is changed way more often than the serializer.

And how do you define often anyway? Sessions are something that are
setup once, it's rarely the case that a programmer needs to change any
of the session INI settings more than once in the same program.

> As I wrote, 3rd party save handler implements their own serializers.
> Not like above example, it is likely called with session_module_name(). e.g.
>
> session_module_name('memcache');
> session_serializer_name('igbinary');

It's your opinion that this is "likely" done that way. I for one have
*never* used session_module_name().
And again, this is not something that people would write more often
than once in the whole application.

> It looks better than
>
> session_module_name('memcached');
> ini_set('session.serializer_handler', 'igbinary');

It doesn't look better than:

ini_set('session.save_handler', 'memcached');
ini_set('session.serialize_handler', 'igbinary');

IMO, this is more explicit and more understandable for people who
haven't read the manuals for the "custom" functions.

> It's reasonable to have session_serializer_name(), since it would be used
> with session_module_name(). API should have good name here, too.

I'm again questioning whether session_module_name() is
useful/necessary in the first place.

> We may discuss what we should do with module functions that modify it's INI.
> There are number of them already. I think you need RFC for this.

On this, I agree.

> My opinion is "There should be API with obvious name, if it is used often or
> mandatory".

On this - not. ;)


Cheers,
Andrey.