Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73178 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68866 invoked from network); 15 Mar 2014 18:33:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2014 18:33:09 -0000 Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.52 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.213.52 mail-yh0-f52.google.com Received: from [209.85.213.52] ([209.85.213.52:45083] helo=mail-yh0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/41-53536-4EC94235 for ; Sat, 15 Mar 2014 13:33:08 -0500 Received: by mail-yh0-f52.google.com with SMTP id c41so3858730yho.25 for ; Sat, 15 Mar 2014 11:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SNvVoSF9ShdSSgNeR0nPHGA6HEa+OlXjD0MKXotln1U=; b=FNvikCBQF0ygn+MSlYKnZGqKSgtElMIiwo6PGAAmHGSIZuaFauJ5+ZhFG4r6VaGkql WJ311FiZRBGR9RF5kgbNt2uKA31E7ybIXwWr7FBdbkDET5mqyfd3DBHqgRc/OOBwYLEu fLXVwqfASE3tJgdEZ91R4tjS6oQh/hzGGGFeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SNvVoSF9ShdSSgNeR0nPHGA6HEa+OlXjD0MKXotln1U=; b=bNKwbHLLCUKoQa1BrgLfZzFAFQg+QEt/T1nLnpPPga++KS8GN9MqOysD4cPHrk+69Q lQC4nMjr/DIuuqqUcUIbJzVkQ+lyPFg7oWDSUYa6qLpttPsH4pE+TvI4Mg1L/yN1gQzM ZOHAuSsvka66nnyulKjQC6o9aIC+A0+q+4uMvDvpWuFP4PGTdfQi5HrcYd0PbLA+400Y PazP/zg2f+ZYonN5ZxVuJiz4YefbbrswTkItw7/aG+TFNyZ9Zro00iTq1qte5VpeJ8We /uG79uXYV3zuCjUr/WmXsnjiQahtr6Bx9TQJvXhRIgG/y9XpinXsEKSUFlgsyCKbd+6c e1rQ== X-Gm-Message-State: ALoCoQkteaH6Cn6NFhjUBgAIE6lZhzlL5Hg38Ocnc7sOIuOSJjtUlo8HOrqIFySm9AevgNrJ3P5q MIME-Version: 1.0 X-Received: by 10.236.74.229 with SMTP id x65mr255495yhd.131.1394908385586; Sat, 15 Mar 2014 11:33:05 -0700 (PDT) Received: by 10.170.188.139 with HTTP; Sat, 15 Mar 2014 11:33:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Mar 2014 20:33:05 +0200 Message-ID: To: Yasuo Ohgaki Cc: Patrick Schaaf , internals , Pierre Joye Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc() From: narf@devilix.net (Andrey Andreev) Hi, On Sat, Mar 15, 2014 at 8:28 AM, Yasuo Ohgaki wrote: > > On Sat, Mar 15, 2014 at 2:10 PM, Andrey Andreev wrote: >> >> On Sat, Mar 15, 2014 at 6:36 AM, Yasuo Ohgaki wrote: >> > Hi all, >> > >> > On Sat, Mar 15, 2014 at 1:15 PM, Yasuo Ohgaki >> > wrote: >> >>> >> >>> >> >>> Now back to the main topic: >> >>> >> >>> Please exclude session_serializer_name(), session_gc(), >> >>> session_reset(), session_abort() and the "session write short-circuit" >> >>> from the 5.6 branch. >> >> >> >> >> >> I removed session_serializer_name() and session_gc() >> >> (Although session_gc() is mandatory API, IMO) >> >> I like the idea removing INI modifying function in the future release. >> >> >> >> I don't understand reason why you insist removal of session_reset() >> >> and session_abort(). They are just missing API for session module, >> >> like session_gc(). >> >> >> >> There should be API (i.e. function/method or parameters) for distinct >> >> operations that user may use. >> >> >> >> I may agree if you could provide the reason why there should not be >> >> these APIs. >> >> session_abort(), session_reset() are just two functions that somebody >> asked about in 2002 via bugs.php.net and nobody responded (11 years >> without a single comment) right up until you just assumed it's a good >> idea and commited it. If it was "missing API", surely at least 1 user >> per year would've requested it. ;) >> >> I understand that you see them as small, trivial additions, but being >> a part of sessions automatically makes them very important and as >> such, they should be evaluated collectively, not by a single person. > > > It does not explain why it is not needed. I'll just repeat what I've said previously: acceptance of a new feature can't be justified by a lack of "why not" reasons, it should work the other way around. > For example, session_abort() can be used to with error/exception during > execution. > You may not use, but I would use it to make sure $_SESSION would not > contains > any unneeded changes when error/exception occurred. I also want to use a lot of features that don't currently exist in PHP, but only few people like yourself have the privilege of being able to commit them. However, everything should go through peer review _before_ it gets in, not after. >> > "write short circuit" omits "write" when $_SESSION hasn't change. There >> > is >> > no point calling write API and writing to storage for the same data. >> >> "write short circuit" as I understand it, is an exact copy of the >> 'lazy_write' option. This will be addressed in the previously >> mentioned RFC that I'll post later today. > > > No. It's not. > > "lazy_write" does not lock session data while "write short circuit" does. > In other words, "lazy_write" changes session behavior, but "write short > circuit" does not. > i.e. With locked session data, "write short circuit" would not change how > session manager works. I can't stress enough how confusing and potentially unsafe that is. Cheers, Andrey.