[tarantool-patches] Re: [PATCH 2/2] swim: implement and expose transport-level encryption

[Konstantin Osipov]

* Vladislav Shpilevoy <v.shpilevoy at tarantool.org> [19/05/08 12:03]:

First, I think you're solving a non-problem.
There is no big deal in passing the crypto algorithm again.


Second, I think the encryption is optional and fairly independent
on the rest of the so it's OK to set it separately
in swim_set_codec(). No need to rework entire configuration
because of encryption issues.

Otherwise I don't have a strong opinion. Passing -1 is ugly, you
could put a lipstick on the pig by using a special enum value
(SWIM_KEEP_CODEC) instead.

> I rethought the API and decided that it lacks
> flexibility - I can't change private key without
> passing crypto algorithm again, in swim_set_codec.
> 
> There are some solutions:
> 
>   - Move algo and key to swim_cfg, and make both of them
>     optional. But it pads out swim_cfg(), which at this moment
>     is quite compact, atomic, and contains only really
>     necessary parameters.
> 
>   - Make swim_set_codec arguments optional. Then a one could
>     change private key like this: swim_set_codec(-1, new_key).
> 
> These solutions are simple and not too intrusive. But probably we
> should do something more global - get rid of swim_cfg and split it
> into separate
> 
>     swim_set_<option>(option_value)
> 
> functions. It will look like this:
> 
>     swim_listen()
>     swim_set_uuid()
>     swim_set_ack_timeout()
>     swim_set_heartbeat_rate()
>     swim_set_gc_mode()
>     swim_set_codec()
>     swim_set_payload()
> 
> Therefore it won't be atomic to update several parameters at once.
> On the other hand, it looks more consistent and just like box.cfg.
> Now the API looks like this:
> 
>     swim_cfg(uri, heartbeat, ack, gc, uuid)
>     swim_set_codec()
>     swim_set_payload()
> 
> Please, tell your opinion.

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32