Re: Revert session_serializer_name(), session_gc()

From: Date: Wed, 12 Mar 2014 16:00:44 +0000
Subject: Re: Revert session_serializer_name(), session_gc()
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue, Mar 11, 2014 at 2:37 PM, Andrey Andreev <[email protected]> wrote:

> Hello,
>
> 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.
> And while session_serializer_name() is just redundant, session_gc()
> could cause performance issues.
>
> I'd strongly suggest that these 2 functions should be removed before
> PHP 5.6 is officially released.
>
> Regards,
> Andrey Andreev.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hello guys,

When we branched 5.6, we branched it from master, with these commits into
it.
Ferenc did a hard job to spot what was in master at this time, and it looks
like he didn't notice those addings.

We should revert them.

We *cannot* accept new functions in 5.6 , if the community in its whole,
does not agree with them, by voting an RFC.
I'm sorry, but that is our policy, and we are not talking about "little"
functions we could blindly accept (because we are not bad dragons neither
:-p, some things are tiny and can be merged without heavy RFC process).
Those changes impact the session module, which is an important one.

Yasuo : I know you are actually working on RFCs for sessions for 5.6. I
would love to see them accepted and merged to 5.6. From what I know, one
has already been accepted partially (
https://wiki.php.net/rfc/session-lock-ini ).
It seems like it's not been
merged yet ?
Is it because it cant, like you seem to say in
http://markmail.org/message/dcykcmq6exvkflf7
?
Please, also remember that we are going to tag beta1 on 18th , your RFCs
need to be accepted and merged for this date.


Having said that, I agree we should clean the session API.
I agree session_module_name() is very uncommon and likely not very used,
and it should dissapear.
I agree as well that having to touch INI settings with ini_set() to change
the session behavior is not really nice, and that those should be feasable
using functions, or arguments to session_start();
However, all those points are BC breaking points, and can not be addressed
for 5.6 ; but I encourage all of you to start discussions about the session
module and those points, for PHP6.

Thank you all for your understanding, we all want to make PHP better, but
we all are humans :-p

Julien.Pauli


Thread (41 messages)

« previous php.internals (#73086) next »