From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A5F6525956 for ; Tue, 6 Aug 2019 16:48:00 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJvLepU8WRza for ; Tue, 6 Aug 2019 16:48:00 -0400 (EDT) Received: from smtp63.i.mail.ru (smtp63.i.mail.ru [217.69.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 67ACD25827 for ; Tue, 6 Aug 2019 16:48:00 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v1 1/3] box: rfc for stacked diagnostic area in Tarantool References: <101e2b28c29ebfc4cf58b45e534207fd4f6d9b3a.1564657285.git.kshcherbatov@tarantool.org> <2ea0273d-db4d-9733-f650-e2c6fc7d4416@tarantool.org> <06bd2140-3d2b-4bc3-7bc4-5f3d293bf891@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Tue, 6 Aug 2019 22:50:24 +0200 MIME-Version: 1.0 In-Reply-To: <06bd2140-3d2b-4bc3-7bc4-5f3d293bf891@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Kirill Shcherbatov , tarantool-patches@freelists.org Hi! Thanks for the answers! CCed tarantool-patches back. On 06/08/2019 10:05, Kirill Shcherbatov wrote: >> 3. VShard uses unpack: https://github.com/tarantool/vshard/blob/a6826b26f9ab38e338a34cb7dd7f46dabbc67af5/vshard/error.lua#L149 >> Is it compatible with what you are doing? Here I need to turn an error into a table to >> set a different serialization method. >> >> 4. Have you considered an idea to unpack errors not as an array, but >> as a list? When each error object has a field 'reason' pointing to >> another object, and so on. It would allow not to change unpack() output >> format - it would still return the newest error, but with a new field. > > I designed :unpack() method to produce an output similar to backtrace. > But maybe it is not really our priority and taking into account your (3)th comment > we should better use reason-based list. Please, ask other people. >> 9. Please, describe the new binary protocol in the similar way as it >> is done here: https://github.com/tarantool/tarantool/blob/master/doc/rfc/3328-wire_protocol.md#body >> And add it to the docbot request with code values included. > > Is I sad in other letter, designing of iproto errors transfer may not be implemented in scope of this > patch series. Maybe it worth to remove this paragraph from RFC at all. > Ok, then remove, please, or move to a section 'plans', 'alternatives', etc.