On 09/22/2014 02:36 PM, Corey Minyard wrote: >> Hmm, thinking aloud here. What happens if 'reconnect' is provided with a >> 'server':true socket? The documentation only specifies 'server':false >> behavior. Should it be an error (incompatible options), or just be >> silently ignored? > > I was going on the behavior of "telnet" and "wait", which are silently > ignored for client sockets. reconnect is silently ignored for server > sockets.
I can live with that.
>
>> Going further, would it be possible to treat 'ChardevSocket' as a flat
>> union, where 'server' is the enum key that determines what other fields
>> are valid? Granted, for this to work, we'd need to teach the qapi
>> generator to allow a discriminator of type bool (since we can enumerate
>> all of its values). looking something like:
>>
>> { 'type': 'ChardevSocketBase',
>> 'data': { 'addr': 'SocketAddress', '*nodelay': 'bool' } }
>> { 'type': 'ChardevSocketServer',
>> 'data': { '*wait': 'bool', '*telnet': 'bool' } }
>> { 'type': 'ChardevSocketClient',
>> 'data': { '*reconnect': 'int' } }
>> { 'union': 'ChardevSocket', 'base': 'ChardevSocketBase',
>> 'discriminator': 'bool',
>> 'data': { true : 'ChardevSocketServer',
>> false: 'ChardevSocketClient' } }
Of course, this is invalid JSON. In a JSON dictionary, the left side of
any 'key':'value' pair must be a string, only the right side can be an
arbitrary JSON type. So we'd have to spell out the stringized version
'true' and 'false' as the enum keys, which is all the more special
casing to be added to the qapi generator. Lots of work for not too much
benefit.
>>
>> but I don't know if it is worth the complexity for the added type safety.
>>
>
> Doesn't seem terrible, but I'm not sure.
You're welcome to try it if you're interested, but in just typing this
email, I can already see it's not a beginner's project, so I'm not going
to insist.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
