From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp21.mail.ru (smtp21.mail.ru [94.100.179.250]) (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 7D1D84696C3 for ; Fri, 17 Apr 2020 00:06:07 +0300 (MSK) References: <767fd7dee482d61cda4e2c7c9e938628bbd7f84d.1586505741.git.lvasiliev@tarantool.org> <38ee9237-e6a2-24a5-b418-8ca05d5e16e1@tarantool.org> <94b59a28-8387-3b7a-8667-f92cd8dbfc18@tarantool.org> <7fcb54c9-0fc3-65b8-4c32-3370e811debe@tarantool.org> From: Vladislav Shpilevoy Message-ID: <70497401-21cc-92ad-f596-38af99c3f484@tarantool.org> Date: Thu, 16 Apr 2020 23:06:05 +0200 MIME-Version: 1.0 In-Reply-To: <7fcb54c9-0fc3-65b8-4c32-3370e811debe@tarantool.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Tarantool-patches] [PATCH v2 5/5] iproto: Update error MsgPack encoding List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: lvasiliev Cc: tarantool-patches@dev.tarantool.org Thanks for the answers! >>>> 7. Why are these values in a enum? I thought we >>>> decided to use string types? >>> Now we compare a string with error type when encode and use number further. If we encode error type as string we still have to compare the strings when decoding to create the error of the desired type. But number takes up less space versus string  when transmitting over a network and makes it possible to use a switch when create an error after decoding (which looks much nicer). >> >> Wait, so this is inside the MessagePack too? This is not a good >> idea really. I thought you just converted strings to enums and >> then enums to classes. > Yes. It's not inside the MessagePack. MP_ERROR decodes by > external handler as we discussed. It registered by > luamp_set_decode_extension(). I meant it is inside MessagePack protocol, not library. >> First about 'less space'. These are error objects. It does not >> really matter if every one of them becomes +10 or even +20 bytes >> if we use string types instead of numbers. They are not critical >> in any aspect, not in perf nor in space. >> >> Second about switch, 'which looks nicer'. Nicely formatted if-else >> sequence also look fine. This is subjective though. I won't argue. >> >> Thirdly, about why I think string types are better. The problem is >> that I don't want us to document all the error types as numbers >> and support them forever. When we use strings, we easily can remove >> old errors, add new errors. When we use numbers, we >> >>      1) will need to document what every number means. Strings are >>      self-documenting. OutOfMemory means out of memory, obviously. >>      And so on. > Ok. >> >>      2) will one day have holes in these numbers left from removed >>      errors, this won't look nice, trust me. > Ok. >> >>      3) that complicates compatibility. What if some error type was >>      added to a newer tarantool version, and an old connector connected >>      to the instance? How will it handle the new error types? With >>      string types the problem does not exist. > If I understand you correctly, you will have the same problem > with string, because you can't create an error of unknown type. String is the type. Client's connector don't need to keep a track of all existing error types, and validate every incoming string. The connector just need to be able to decode MP_STR, and that is all. When you have numbers, client can't tell error type, if a new unknown number is received. Instead of a nice human readable error type it will be just an abstract number like '252'. With string types whatever new errors are added in newer versions, all client connectors will be able to decode them without necessity to validate.