From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (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 53535441841 for ; Wed, 25 Mar 2020 11:27:09 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id v4so1001834lfo.12 for ; Wed, 25 Mar 2020 01:27:09 -0700 (PDT) Date: Wed, 25 Mar 2020 11:27:07 +0300 From: Konstantin Osipov Message-ID: <20200325082707.GB18984@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v2 01/10] box: rfc for stacked diagnostic area List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Nikita Pettik [20/03/25 09:32]: > From: Kirill Shcherbatov > > Part of #1148 This RFC is lgtm. I wonder how it corresponds with capability negotiations. If we have capability negotiations, we don't need iproto_error_stack *and* iproto_error messages in the protocol, we can negotiate with the client whether or not it's ready to receive iproto_error_stack. However, I think capability negotiation in client-server protocol is an overkill. Gradually phasing out old client support is a cleaner strategy. And simply preserving backward compatibility, which is already possible with extra fields ignored by old clients, is even better. -- Konstantin Osipov, Moscow, Russia