Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79392 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31186 invoked from network); 3 Dec 2014 09:22:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Dec 2014 09:22:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:42811] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/E0-15597-276DE745 for ; Wed, 03 Dec 2014 04:22:58 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id 0E0E923D6007; Wed, 3 Dec 2014 10:22:54 +0100 (CET) Received: from 217.253.41.29 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Wed, 3 Dec 2014 10:22:54 +0100 Message-ID: In-Reply-To: References: <790a8d7299a7cda01ee76d8293b7d5af.squirrel@webmail.klapt.com> Date: Wed, 3 Dec 2014 10:22:54 +0100 To: "Pierre Joye" Cc: "Anatol Belski" , "PHP internals" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Native TLS From: anatol.php@belski.net ("Anatol Belski") Hi Pierre, On Wed, December 3, 2014 02:36, Pierre Joye wrote: > hi Anatol! > > On Fri, Nov 28, 2014 at 2:54 AM, Anatol Belski > wrote: > >> Hi, >> >> >> this is a long spoken topic which is now embodied in >> https://wiki.php.net/rfc/native-tls . A preliminary implementation is >> there as well, thus we can discuss it. > > Awesome work as usual! > > > > As other mentioned, we should get rid of the TSRM_* macros for > declaratons/calls. Having them as placebo for the sake of having them and > reduce the amount of changes brought by this patch make little sense to > me. Master requires now a lot of changes anyway, we may as well just kill > that while being at it, easy move. Maybe add a vote option to either keep > the placebo (less code change) or remove it (easier in the long term, no > more TS build break, or fewer). > I meant that as well, to the time it's merged all the TSRMLS_* thingies should be removed. I kept them only while developed and now for the RFC so the diff shows the only change done, otherwise it would sink in the unrelevant stuff. Therefore I'd rather stay by the yes/no choice as removing TSRMLS_* is the essential part of the RFC - so better at once then :) As otherwise one can sure find some factor to defer the actual change, but the change is the actual goal. Regards Anatol