Re: [PATCH V4 2/7] qapi/net.json: Add L4_Connection definition

[Markus Armbruster]

Markus Armbruster <armbru@redhat.com> writes:

> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
[...]
>>                                     I think there should also beb
>> a separate type that represents an IP address+port, so that what you end
>> up with is:
>>
>>   IPFlowSpec
>>      ID
>>      Protocol
>>      Source
>>      Dest
>
> I understand the motivation.  Three drawbacks, though.
>
> One, it gets us another level of nesting on the wire, i.e. something
> like
>
>     {"source": {"address": SRC-ADDR, "port": SRC-PORT},
>      "destination": {"address": DST-ADDR, "port": DST-PORT}}
>
> instead of
>
>     {"source-address": SRC-ADDR, "source-port": SRC-PORT,
>      "destination-address": DST-ADDR, "destination-port": DST-PORT}
>
> QMP clients shouldn't care.
>
> Two, we have many (address, port) pairs in the schema that don't use
> nesting.  Adding nesting sometimes makes QMP less consistent.
>
> Three, human-friendly interface wrappers tend to dislike nesting.  This
> particular case seems okay; we end up with dotted keys like
> source.address instead of source-address.  In a case where we need just
> one (address, port), we'd get some-silly-name.address instead of just
> address, though.
>
> I've occasionally felt a mild need for letting me say "this struct
> member should be unboxed on the wire", i.e. have its curlies peeled off.
> Never enough to justify the additional generator complexity, though.

Just remembered we actually have

    ##
    # @InetSocketAddressBase:
    #
    # @host: host part of the address
    # @port: port part of the address
    ##
    { 'struct': 'InetSocketAddressBase',
      'data': {
        'host': 'str',
        'port': 'str' } }

It's from commit eb87203b64 "rbd: Reject -blockdev server.*.{numeric,
to, ipv4, ipv6}".