Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73086 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56156 invoked from network); 12 Mar 2014 16:01:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Mar 2014 16:01:29 -0000 Authentication-Results: pb1.pair.com smtp.mail=julienpauli@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=julienpauli@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.180 as permitted sender) X-PHP-List-Original-Sender: julienpauli@gmail.com X-Host-Fingerprint: 209.85.128.180 mail-ve0-f180.google.com Received: from [209.85.128.180] ([209.85.128.180:51614] helo=mail-ve0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0E/E6-17005-7D480235 for ; Wed, 12 Mar 2014 11:01:28 -0500 Received: by mail-ve0-f180.google.com with SMTP id jz11so10110302veb.39 for ; Wed, 12 Mar 2014 09:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=hcPYcVbPjJAObR416QohfdZdw9RGRVhBlxqxYlCtmL4=; b=prgUTFYu/VaWpIRIyMKBffS9mVBLy3txv+TvhydYyRFamuYZqwM+9oK90HEUwEHgeN hKzMyoXcieWfwZN9vFYh5fevG53cPShODNNxV7bqpQ0HpPvilxNu7ZkVl7SiwGntbO6S /oNZo2uqlNvEDPk0tQfAPKXPG131CRtC2MtnL2Qb1dPKmjS2S3GX6scJQTPpzlZhePbU gdtIyaomQrLLHPxETJfeaYYRw1RZgu7eb/rFo89cE3F/6GpjDyP9DE+5+HHIbwVBrsBh I9v3vLwOhx5/Ub8/Ep0lhHQJy+ghuGfmk5Oo5oqQxPnXtdSEKmmiR5OpmTqqifwouAtm wwkw== X-Received: by 10.220.247.68 with SMTP id mb4mr720431vcb.37.1394640084288; Wed, 12 Mar 2014 09:01:24 -0700 (PDT) MIME-Version: 1.0 Sender: julienpauli@gmail.com Received: by 10.220.81.68 with HTTP; Wed, 12 Mar 2014 09:00:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Mar 2014 17:00:44 +0100 X-Google-Sender-Auth: NvxV1HStkK4coPOf7X2vz-5AMzY Message-ID: To: Andrey Andreev Cc: "internals@lists.php.net" , Yasuo Ohgaki , Ferenc Kovacs Content-Type: multipart/alternative; boundary=089e0122aa5cd0731c04f46af264 Subject: Re: [PHP-DEV] Revert session_serializer_name(), session_gc() From: jpauli@php.net (Julien Pauli) --089e0122aa5cd0731c04f46af264 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 11, 2014 at 2:37 PM, Andrey Andreev 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 --089e0122aa5cd0731c04f46af264--