From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id EEB104696C3 for ; Wed, 25 Mar 2020 13:56:53 +0300 (MSK) Received: by mail-lj1-f196.google.com with SMTP id w1so1928288ljh.5 for ; Wed, 25 Mar 2020 03:56:53 -0700 (PDT) MIME-Version: 1.0 References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> <20200325084205.GG18984@atlas> In-Reply-To: <20200325084205.GG18984@atlas> From: Eugene Leonovich Date: Wed, 25 Mar 2020 11:56:27 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000dc5c7705a1abb920" 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: Konstantin Osipov , lvasiliev , alexander.turenko@tarantool.org, tarantool-patches@dev.tarantool.org --000000000000dc5c7705a1abb920 Content-Type: text/plain; charset="UTF-8" > 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 --000000000000dc5c7705a1abb920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 com= promise. In my humble opinion, the extended error feature in its current st= ate is not worth the complexity and overhead it adds. Instead, why not intr= oduce 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 wi= ll 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 chan= ged to use the new error type, the setting itself will be marked as depreca= ted 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 t= he response body, which would mean that the connector has received a "= new" error.

--
Thank you and best regards,
Eugene Leonovich
--000000000000dc5c7705a1abb920--