Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73342 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30203 invoked from network); 20 Mar 2014 18:35:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Mar 2014 18:35:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=john.lesueur@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=john.lesueur@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender) X-PHP-List-Original-Sender: john.lesueur@gmail.com X-Host-Fingerprint: 209.85.212.179 mail-wi0-f179.google.com Received: from [209.85.212.179] ([209.85.212.179:38888] helo=mail-wi0-f179.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E9/00-33112-DF43B235 for ; Thu, 20 Mar 2014 13:35:42 -0500 Received: by mail-wi0-f179.google.com with SMTP id f8so1097538wiw.12 for ; Thu, 20 Mar 2014 11:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTMxURRIYstoPJTzy1RUbuBVSQx4ccR4frRkvJdWO38=; b=DZ1hDEfUrnv1FJlSR/4OX/6aSRPSydCRuLZPeJ6Tt126N9IN0ZdXGNyzzISPLSNjeU JKK11bvmT4nflc3EilvirFTlW2VSxmeh+mjnf0nDX5m+1OE+f2+XA4X3VBB/Pyw6uApP 2fDxbWaP0CtZj+nY8fD5hDMDgiJhk0BxfwaEgO7NLSgtuaCh8C6aFuK7Vstk2yBc7Ajq MN0NQfrqC6TXk8hl08LFON0r5+nM/NuVndBHV+5MInyS56o7HEDAdyK3XRzyx4kZKQaD G3j/vdIbBYzfgO+ZODzRGkT5OY6DZOxx/FY0ROEbgIHa0r0/KN4BOl7MAp+TaOgvgNGl 6u4A== MIME-Version: 1.0 X-Received: by 10.180.36.8 with SMTP id m8mr25475988wij.42.1395340539020; Thu, 20 Mar 2014 11:35:39 -0700 (PDT) Received: by 10.216.234.138 with HTTP; Thu, 20 Mar 2014 11:35:38 -0700 (PDT) In-Reply-To: References: <5324FE40.1070704@sugarcrm.com> <532603A0.8060802@sugarcrm.com> <5327DD6E.6030402@sugarcrm.com> Date: Thu, 20 Mar 2014 12:35:38 -0600 Message-ID: To: Andrey Andreev Cc: Yasuo Ohgaki , Stas Malyshev , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=e89a8f5032e22b4d5004f50e0955 Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about read_only, lazy_write sessions From: john.lesueur@gmail.com (John LeSueur) --e89a8f5032e22b4d5004f50e0955 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 5:19 AM, Andrey Andreev wrote: > Hi all, > > I did this prototype/concept about SessionHandler, > SessionHandlerInterface in PHP 5.6: > https://gist.github.com/narfbg/9643416 > In the context of this discussion, the important part is the > updateTimestamp() method (in relation to 'lazy_write'), you should > ignore the rest (for now). I want to discuss it here first before > updating the RFC with it. > > So, I had a chat with Yasuo about it to identify the problems and/or > limitations and this is the most important one: > > The patch (https://github.com/php/php-src/pull/628) doesn't allow > calling parent::updateTimestamp() and users should call > parent::write() instead. This is because there are PECL extensions > that provide a session handler and they won't have support for that, > which is hard to detect at runtime. > However, I don't think that this is convenient, nor that documenting > this is better than documenting that PECL extensions might not support > the parent::updateTimestamp() call. To me, that's an unnecessary > limitation and here are the alternatives: > > 1. Don't declare SessionHandler::updateTimestamp() if > session.save_handler doesn't support it and put a big red warning in > the docs that PECL extensions might lack the method. > > I think this is a good trade-off, given that most users trust (or > have) only "stock" PHP extensions and can benefit from this. > Also, this wouldn't be a precedent - you can take mysqli and it's > dependancies on mysqlnd for example (where the docs mention this very > briefly). > > 2. Scrap the updateWhatever() method and just modify write() to only > update the timestamp when necessary. > > I have no idea why nobody has thought about this previously. The > 'lazy_write' idea is inspired by a feature request from 2002 > (https://bugs.php.net/bug.php?id=17860) that simply asks for an API > identifying whether $_SESSION has been changed or not, or in other > words - and API saying whether session data or only the timestamp > should be updated. > > Now, Yasuo prefers providing explicit API for the lazy_write feature > (namely, the updateTimestamp() method), but simply providing such a > flag via i.e. yet another magic constant, similar to SID, solves ALL > of the problems: > > - No API changes > - No BC breaks > - No effect on PECL extensions that don't support it > > IMO, that's way more flexible and would allow doing lazy_write by > default, no option - after all, the feature represents a performance > improvement. > It also solves another, side-effect problem: the > SessionUpdateTimestampInterface, that currently exists only because of > internal implementation details. > > Thoughts? More suggestions? Concerns? > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Just an unimportant note on the name of the function. Having done this in a custom session handler, I have always thought of this as an analogue to the "touch" command for the filesystem. Naming this SessionHandler::touch() would probably appeal to those familiar with linux or other posix compliant systems. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html Thanks, John --e89a8f5032e22b4d5004f50e0955--