Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73256 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9765 invoked from network); 18 Mar 2014 05:45:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2014 05:45:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:37966] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/A8-17561-17DD7235 for ; Tue, 18 Mar 2014 00:45:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 8A8DA513D2; Tue, 18 Mar 2014 01:45:19 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 1EF6750DE4; Tue, 18 Mar 2014 01:45:19 -0400 (EDT) Message-ID: <5327DD6E.6030402@sugarcrm.com> Date: Mon, 17 Mar 2014 22:45:18 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yasuo Ohgaki , Andrey Andreev CC: "internals@lists.php.net" References: <5324FE40.1070704@sugarcrm.com> <532603A0.8060802@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I agree. > If nobody objects, I'll remove the option. Please send mail ASAP! I think defaults should not change in minor version, unless there's a very good reason for it, and here it's not a very good reason. Session module is very sensitive, and doing changes in it should be very conservative to not break people's workflows. While new behavior serves an important use case, it may not be everybody's use case, especially with all handlers. Thus, I would rather have it an option - exactly as voted. When we move into PHP 6, where certain major changes are expected, we can change the defaults. But I think introducing such change in a minor version is unnecessary risk. And also it subverts RFC process as it's not what the vote was for, and it's a substantial change - default behavior change (means, everybody affected) instead of option (means, only people using the option affected). > When is the beta due? I made PR so that RMs can merge it. I'd recommend waiting for it to be thoroughly reviewed before merging. I myself will try to take a look in coming days, as my schedule allows, but it may take time to polish some things. Sessions are very sensitive area, so we need to be very careful. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227