On Wed, Jul 06, 2022 at 04:07:43PM +0100, Daniel P. Berrangé wrote: > On Wed, Jul 06, 2022 at 09:53:43AM -0500, Andrea Bolognani wrote: > > Yeah but we're generating structs for all possible events ourselves > > and we don't really expect external implementations of this > > interface so I don't see what having this getter buys us over the > > guarantee, that we have by construction, that all events will have a > > public member with a specific name that contains the timestamp. > > Code doesn't neccessarily want to deal with the per-event type > structs. It is credible to want to work with the abstract 'Event' > interface in places and being able to get the Timestamp from that, > without figuring out what specific event struct to cast it to first.
Makes sense. > > I still don't like the fact that we have to force clients to use a > > non-standard API, or that the API for events has to be different from > > that for unions. But Go won't let you add method implementations to > > an interface, so we're kinda stuck. > > I think this specific case is out of scope for the "standard" JSON > APIs, and somewhere you'd expect APIs to do their own thing a layer > above, which is what we're doing here. > > More importantly though what we're generating in terms of QAPI derived > APIs should be thought of as only the first step. Ultimately I would > not expect clients to be marshalling / unmarshalling these structs at > all. So from that POV I think the question of "non-standard" APIs is > largely irrelevant. > > Instead we would be providing a "QMPClient" type with APIs for sending/ > receiving instances of the 'Command'/'Response' interfaces, along with > callback(s) that receives instances of the 'Event' interface. Any JSON > marshalling is hidden behind the scenes as an internal imlp detail. I will note that we want the marshalling/unmarshalling part and the wire transfer part to be somewhat loosely coupled, to allow for use cases that are not covered by the high-level client API, but overall I now agree with you that for most users this shouldn't ultimately matter :) -- Andrea Bolognani / Red Hat / Virtualization