From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (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 B1F8A441841 for ; Fri, 27 Mar 2020 11:39:07 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id 19so9297962ljj.7 for ; Fri, 27 Mar 2020 01:39:07 -0700 (PDT) Date: Fri, 27 Mar 2020 11:39:05 +0300 From: Konstantin Osipov Message-ID: <20200327083905.GC3620@atlas> References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> <20200326233535.mixxirv5336d5rnh@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200326233535.mixxirv5336d5rnh@tkn_work_nb> 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: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org * Alexander Turenko [20/03/27 11:14]: > > > 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. > It's a good idea to extend existing packets in backward compatible manner if it can be done in a meaningful way and without breaking old clients. All tarantool clients should ignore unknown map keys. -- Konstantin Osipov, Moscow, Russia