Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:97281 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71078 invoked from network); 5 Dec 2016 03:32:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2016 03:32:00 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:48092] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/F1-42090-DAFD4485 for ; Sun, 04 Dec 2016 22:31:59 -0500 Received: (qmail 125315 invoked by uid 89); 5 Dec 2016 03:31:54 -0000 Received: from unknown (HELO mail-wm0-f42.google.com) (yohgaki@ohgaki.net@74.125.82.42) by 0 with ESMTPA; 5 Dec 2016 03:31:54 -0000 Received: by mail-wm0-f42.google.com with SMTP id t79so72640818wmt.0 for ; Sun, 04 Dec 2016 19:31:52 -0800 (PST) X-Gm-Message-State: AKaTC00F9QHDScZDuAXqz57evIbymGW3WvcldErPNTx2Sqc0pJ3g59XYRWDt48/NYAAAWagtlGBkrSGhrpYX5Q== X-Received: by 10.28.174.76 with SMTP id x73mr7396596wme.25.1480908706103; Sun, 04 Dec 2016 19:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.38.7 with HTTP; Sun, 4 Dec 2016 19:31:05 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Dec 2016 12:31:05 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Marco Pivetta Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC][VOTE] User defined session serializer From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi Marco, Thank you for explaining the reason why! On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta wrote: > I voted "no" because I don't see any advantage over using a custom session > save handler, besides adding more API that partially covers custom session > save handlers. You mean current OO custom save handler, I suppose. Firstly, current OO custom save handler design (use of previously used internal save handler as its base class) is not good. Overriding open()/close()/etc are useless, moreover harmful. Number of bugs proved it is not good. Secondly, the only use case, that current OO save handler design is useful, is read()/write() override to encrypt/validate session data. Thirdly, I fixed _many_ of current OO API bugs, but fixing them all is impossible by design. Current OO save handler API is wrong in many ways and should be deprecated and replaced by clean OO API as mentioned in the RFC. Is there any good reasons to keep problematic API for good? > This is just confusing, in my opinion, and the API can be replicated in > userland with a custom session save handler decorator instead. I may be too familiar to session module. I don't understand what's confusing. Session module has 2 distinct submodules for saving and serializing data. These have different tasks. The RFC allows to save session data in whatever format. e.g. XML/JSON/BSON/etc. This is _impossible_ by save handler submodule. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net