On Wed, 16 Mar 2011 15:49:59 +0100 Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 03/16/2011 03:34 PM, Luiz Capitulino wrote: > > +## > > +# @put_event: > > +# > > +# Disconnect a signal. This command is used to disconnect from a signal > > based > > +# on the handle returned by a signal accessor. > > +# > > +# @tag: the handle returned by a signal accessor. > > +# > > +# Returns: Nothing on success. > > +# If @tag is not a valid handle, InvalidParameterValue > > +# > > +# Since: 0.15.0 > > > > The name 'signal' (at least today) doesn't make sense on the wire protocol, > > 'put_event' probably doesn't make sense in the C library, nor does 'event'. > > > > Another detail is that, event extension is more important than command > > extension, because it's probably going to happen. I think it would be very > > bad to add new events just because we wanted to add a new field. > > What if events were always passed a single struct, with the first field > being a bitmask saying which (or how many) fields have been filled? > > It is quite ugly to work that way when calling functions, but it's not > too bad when you are writing the callees. And it's the code generator > that writes the function calls in the case of libqmp... I was also wondering if it's possible to only make the most recent version available in the wire protocol and all existing ones in libqmp. But I need to read more code in order to know that.
