From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 9F72E4696C3 for ; Fri, 17 Apr 2020 10:35:42 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id j3so983736ljg.8 for ; Fri, 17 Apr 2020 00:35:42 -0700 (PDT) Date: Fri, 17 Apr 2020 10:35:40 +0300 From: Konstantin Osipov Message-ID: <20200417073540.GA4007@atlas> References: <9ad134f42e6b11bf030f80d90435aac512db0784.1587058424.git.lvasiliev@tarantool.org> <20200416194835.GA3623@atlas> <4ff74326-f83d-599d-fcda-c7d8175c9263@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ff74326-f83d-599d-fcda-c7d8175c9263@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH V4 4/6] error: add session setting for error type marshaling List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [20/04/17 10:16]: > Seems like you are talking about the case when error object is > thrown as an exception. But the patchset is about being able to > recognize and decode errors even when they are returned inside > response body, as a part of IPROTO_OK response type. Then you think this justifies inventing a custom marshalling scheme and thus forcing all clients to not just patch the driver but also patch or even re-implement msgpack library they use? Worse yet, with such a huge protocol change you can add complete marshalling of any object - SQL parse tree, Lua thread along with all its referenced objects, Lua code and stack data, and what not -- all very desired for other features, like distributed SQL or shipping/executing Lua code close to data. Worse *yet*, it's quite possible to add all these features without an MP_EXT. But this doesn't concern you at all. So what about an RFC? -- Konstantin Osipov, Moscow, Russia