On Tue, 15 Feb 2011 10:20:01 +0100
Kevin Wolf <kw...@redhat.com> wrote:
> Am 14.02.2011 20:34, schrieb Anthony Liguori:
> > On 02/14/2011 12:34 PM, Luiz Capitulino wrote:
> >> On Mon, 14 Feb 2011 08:39:11 -0600
> >> Anthony Liguori<anth...@codemonkey.ws> wrote:
> >>
> >>
> >>> On 02/14/2011 06:45 AM, Luiz Capitulino wrote:
> >>>
> >>>> So the question is: how does the schema based design support extending
> >>>> commands or events? Does it require adding new commands/events?
> >>>>
> >>>>
> >>> Well, let me ask you, how do we do that today?
> >>>
> >>> Let's say that I want to add a new parameter to the `change' function so
> >>> that I can include a salt parameter as part of the password.
> >>>
> >>> The way we'd do this today is by checking for the 'salt' parameter in
> >>> qdict, and if it's not present, use a random salt or something like that.
> >>>
> >> You likely want to do what you did before. Of course that you have to
> >> consider if what you're doing is extending an existing command or badly
> >> overloading it (like change is today), in this case you'll want to add
> >> a new command instead.
> >>
> >> But yes, the use-case here is extending an existing command.
> >>
> >>
> >>> However, if I'm a QMP client, how can I tell whether you're going to
> >>> ignore my salt parameter or actually use it? Nothing in QMP tells me
> >>> this today. If I set the salt parameter in the `change' command, I'll
> >>> just get a success message.
> >>>
> >> I'm sorry?
> >>
> >> { "execute": "change", "arguments": { "device": "vnc", "target":
> >> "password", "arg": "1234", "salt": "r1" } }
> >> {"error": {"class": "InvalidParameter", "desc": "Invalid parameter
> >> 'salt'", "data": {"name": "salt"}}}
> >>
> >
> > So I'm supposed to execute the command, and if execution fails, drop the
> > new parameter? If we add a few optional parameters, does that mean I
> > have to try every possible combination of parameters?
>
> How is that different from trying out multiple commands? In the end, you
> always need some meta information like a schema in order to avoid trying
> out which parameters the server supports.
>
> Anyway, I think there's a second interesting point: Adding parameters
> does cause these problems, but it's different for data sent from qemu to
> the client (return values and events). If we add more information there,
> an older client can just ignore it, without even looking at a schema.
>
> So I think we should consider this for return values and definitely do
> it for events. Sending out five different messages for a single event
> that are completely redundant and only differ in the number of fields is
> just insane (okay, they wouldn't actually get on the wire because a
> client registers only for one of them, but the code for generating them
> must exist).
That's my point when I asked about events in the other thread.
> > You're arguing that we should extend commands by adding new parameters.
> > I'm saying that's a bad interface. If we need to change a command, we
> > should introduce a new command. It's a well understood mechanism for
> > maintaining compatibility (just about every C library does exactly this).
>
> I'm yet undecided about adding parameters. I have a feeling that you
> might be right here.
>
> Kevin
>
