Het Gala <[email protected]> writes:
> On 30/05/23 12:28 pm, Markus Armbruster wrote:
>> Het Gala<[email protected]> writes:
>>
>>> On 25/05/23 11:04 pm, Markus Armbruster wrote:
[...]
>>>> Aside: a more powerful type system would let us extend SocketAddress
>>>> with additional variants instead of wrapping it in a union.
>>>
>>> Markus, what do you mean by additional variants here in context of socket?
>>> Can you give a small example.
>>
>> As is, we have a nest of two unions:
>>
>> * The outer union has branches @socket, @exec, @rdma.
>>
>> * Branch @socket is the inner union, it has branches @inet, @unix, ...
>>
>> A more powerful type system would let us extend SocketAddress instead,
>> so MigrateAddress has everything SocketAddress has, plus additional
>> branches @exec, @rdma. Naturally, the type of the discriminator also
>> needs to be extended, so that it has everything SocketAddress's
>> discriminator type has, plus additional members @exec, @rdma.
>
> Okay, so you mean something like :
>
> +# Since 8.1
> +##
> +{ 'union': 'MigrateAddress',
> + 'base': { 'transport' : 'MigrateTransport'},
> + 'discriminator': 'transport',
> + 'data': {
> + 'inet': 'InetSocketAddress',
> + 'unix': 'UnixSocketAddress',
> + 'vsock': 'VsockSocketAddress',
> + 'fd': 'str',
> + 'exec': 'MigrateExecCommand',
> + 'rdma': 'InetSocketAddress' } }
>
> Even I agree that directly leveraging this is the best option, but then
> wouldn't it introduce redundancy ? we would not be able to leverage socket
> union right in that case or am I missing something.
Yes, there's redundancy, due to QAPI's insufficient expressive power.
Is the cleaner external interface worth the (internal) redundancy, and
possibly coding complications that go with it?
