Re: [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase

[Alexander Turenko <alexander.turenko@tarantool.org>]

> > 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.

WBR, Alexander Turenko.