From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 55DF0441841 for ; Thu, 26 Mar 2020 14:37:52 +0300 (MSK) References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> <20200325084205.GG18984@atlas> From: lvasiliev Message-ID: Date: Thu, 26 Mar 2020 14:37:50 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eugene Leonovich , Konstantin Osipov , alexander.turenko@tarantool.org, tarantool-patches@dev.tarantool.org On 25.03.2020 13:56, Eugene Leonovich wrote: > > A much simpler way to do it is to have a server switch to enable > new features. > It is less flexible, of course, because you can't have old and new > clients, but do you really want to have old and new clients? > > > I do agree with Kostya, I think it's a good compromise. In my humble > opinion, the extended error feature in its current state is not worth > the complexity and overhead it adds. Instead, why not introduce a > Tarantool setting to choose whether you want to deal with a legacy or > extended error response type (and it's very unlikely that someone will > need to have 2 types at the same time). By default this setting will be > set to use the legacy mode, then after N minor 2.x releases, it can be > changed to use the new error type, the setting itself will be marked as > deprecated and removed in the next major release. From a connector's > point of view, it will also be easy to check if there are any additional > fields in the response body, which would mean that the connector has > received a "new" error. > > -- > Thank you and best regards, > Eugene Leonovich Hi! Thanks for the feedback. It sounds like a soft break of the backward compatibility. "From a connector's point of view, it will also be easy to check if there are any additional fields in the response body, which would mean that the connector has received a "new" error." - No, the format of a message has been changed. About negotiation phase - it's optional and I think it can be used for flexible session setup in the future (not only for errors). If you use a default settings of the session negotiation phase is absent and don't add additional overhad.