Markus Armbruster <arm...@redhat.com> writes:
> "Dr. David Alan Gilbert" <dgilb...@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}".
