On 10/28/2013 11:22 PM, Wenchao Xia wrote: >> > MONITOR_EVENT seems tide to monitor too much, since it will be present > in qapi-schema, I think Q_EVENT_ or QMP_EVENT_KIND would be better?
I don't have a strong enough opinion on the bikeshed color.
MONITOR_EVENT implies the event is always associated with delivery over
a monitor; but how else would you receive an event without a monitor?
>
> I am coding v2, which fully support event define in qapi-schema. There
> is another thing I hope to know your opinion:
> Should we support use enum as discriminator?
>
> { 'enum': 'QEvent',
> 'data': [ 'SHUTDOWN', 'POWERDOWN']
>
> { 'type': 'QmpEventBase',
> 'data': { 'event': 'QEvent', 'timestamp': 'EventTimestamp' } }
>
> { 'Union': 'QmpEvent',
> 'base': 'QmpEventBase',
> 'discriminator': 'event',
I raised that question when Kevin first added discriminated unions; if I
recall, the answer was along the lines: "yes, it would be a nice
addition, but someone would have to code it, and we'd have to teach the
generator.py to loudly fail if all branches of the enum are not covered
in the union's data". So go for it!
> 'data': {
> 'SHUTDOWN' : 'EventShutdown',
> 'POWERDOWN' : 'EventPowerdown'
> }
> }
>
> By default 'QmpEvent' will generate a hidden enum type 'QmpEventKind'.
> but the hidden type define is needed by query-event, so there is two way
> to archieve it:
> 1 just use the hidden type in qapi-schema.json.
> 2 modified the script to support use predefined enum type.
> In my draft code, both can work, but which one do you prefer?
I'd like to see the addition of an enum-typed discriminator, rather than
forcing the discriminator to be string-only.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
