From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp16.mail.ru (smtp16.mail.ru [94.100.176.153]) (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 E961A4696C3 for ; Fri, 27 Mar 2020 02:35:32 +0300 (MSK) Date: Fri, 27 Mar 2020 02:35:35 +0300 From: Alexander Turenko Message-ID: <20200326233535.mixxirv5336d5rnh@tkn_work_nb> References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> 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: lvasiliev Cc: tarantool-patches@dev.tarantool.org > > Why have it at all and not look at server version, which is part > > of the greeting already? > > > The cause is backward compatibility. > For example: a client application may expect an error as a string (IPROTO_OK > case) and instead of which it will receive an error as an “object”. A > greeting is sent only from the server side to the client, but the server > must know what format should be used to send errors (what format does the > client expect). (After the discussion with Leonid and Vlad.) The new idea appears: don't do any sessions setting / negotiation, but extend IPROTO_OK response in the backward compatible way. (It is a bit wild, I understood.) Send everything inside IPROTO_BODY as usual: with errors as strings. Add the new field into the response, say, IPROTO_ERROR_META. It is mp_map, where keys are offset / path to strings, which were errors. Values are maps, which will contain all necessary data to create full-featured error: error code, backtrace, etc. We possibly can even reuse the format from the stacked disgnostics RFC. We can even strip error messages from this map to reduce traffic. It will be tricky to collect this metainfo during serialization and it will be tricky to replace strings with errors during deserialization. But doable. NB: Whether this mechanism can be reusable for other similar cases? It looks too heavy in coding to do it just for errors. WBR, Alexander Turenko.