From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37430 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PozaH-0002vc-0w for qemu-devel@nongnu.org; Mon, 14 Feb 2011 09:39:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PozaE-0001Kx-97 for qemu-devel@nongnu.org; Mon, 14 Feb 2011 09:39:24 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:58070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PozaE-0001KP-5E for qemu-devel@nongnu.org; Mon, 14 Feb 2011 09:39:22 -0500 Received: by qwk4 with SMTP id 4so3321296qwk.4 for ; Mon, 14 Feb 2011 06:39:21 -0800 (PST) Message-ID: <4D593E8F.7050306@codemonkey.ws> Date: Mon, 14 Feb 2011 08:39:11 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC] qapi: events in QMP References: <4D581E04.1020901@codemonkey.ws> <4D58FADB.3010005@redhat.com> <4D591A01.4030105@codemonkey.ws> <4D5920ED.6020104@redhat.com> <20110214104517.32b77291@doriath> In-Reply-To: <20110214104517.32b77291@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Markus Armbruster , qemu-devel 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. 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. Even if we expose a schema, but leave things as-is, having to parse the schema as part of a function call is pretty horrible, particularly if distros do silly things like backport some optional parameters and not others. If those optional parameters are deeply nested in a structure, it's even worse. OTOH, if we introduce a new command to set the password with a salt, it becomes very easy for the client to support. The do something as simple as: if qmp.has_command("vnc-set-password-with-salt"): qmp.vnc_set_password_with_salt('foobar', 'X*') else: window.set_weak_security_icon(True) qmp.vnc_set_password('foobar') Now you could answer, hey, we can add capabilities then those capabilities can quickly get out of hand. Regards, Anthony Liguori > While the current code is in really in bad shape currently, I'm not sure that > having this disadvantage will pay off the new design. > >