On 11/02/2016 04:57 AM, Kevin Wolf wrote:
>>> IMHO it should allow use of UNIX sockets, as its possible to have
>>> SSH setup a tunnel to a IP server, and expose the endpoint via a
>>> UNIX socket. So even if your reference server only supports IPv4,
>>> users can conceivably connect with any sockets protocol.
>>>
>>
>> This is not a use-case that we have in mind right now, but a very fair
>> point! Kind of like accessing the audio/video streams remotely from my
>> Raspberry Pi over ssh. Is it OK if we target this in a future patch
>> after proper review/testing?
> 
> No, going from InetSocketAddress to SocketAddress changes the API in an
> incompatible way (previously working blockdev-add commands would stop
> working), so we must decide now before the API is introduced.

Going from InetSocketAddress to SocketAddress is a pain because
SocketAddress is a 'simple union' (which really means extra nesting on
the wire).  I'd really rather that blockdev-add move towards the
GlusterServer style of a 'flat union', which CAN be done in a
backwards-compatible manner.  Or, with examples:

InetServer alone:
{ "host": "foo", "port": "1000" }

SocketAddress:
{ "type": "inet", "data": { "host": "foo", "port": "1000" } }

GlusterServer:
{ "type": "tcp", "host": "foo", "port": "1000" }

For comparison, we wrote NFSServer with an eye towards possible
expansion into a flat version (more like GlusterServer than SocketAddress).

NFSServer:
{ "type": "inet", "host": "foo" }


[side note: Uggh - why did we let gluster go into 2.7 with 'tcp' instead
of 'inet' :( I'm wondering if we want gluster in 2.8 to recognize 'inet'
as a synonym for 'tcp'; I could propose a patch if we think it is
worthwhile]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org