From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NcDjZ-0003kx-HM for qemu-devel@nongnu.org; Tue, 02 Feb 2010 03:03:41 -0500 Received: from [199.232.76.173] (port=57820 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NcDjZ-0003kp-1A for qemu-devel@nongnu.org; Tue, 02 Feb 2010 03:03:41 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NcDjW-0006JW-K8 for qemu-devel@nongnu.org; Tue, 02 Feb 2010 03:03:40 -0500 Received: from mx20.gnu.org ([199.232.41.8]:26967) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NcDjW-0006JF-1l for qemu-devel@nongnu.org; Tue, 02 Feb 2010 03:03:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NcDjV-0005Ep-CX for qemu-devel@nongnu.org; Tue, 02 Feb 2010 03:03:37 -0500 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1283ZJ7010470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 2 Feb 2010 03:03:35 -0500 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 0/8]: QMP feature negotiation support References: <1264686180-29845-1-git-send-email-lcapitulino@redhat.com> <20100201162234.0f144f3f@doriath> <20100201175004.5b1b5cc8@doriath> Date: Tue, 02 Feb 2010 09:03:32 +0100 In-Reply-To: <20100201175004.5b1b5cc8@doriath> (Luiz Capitulino's message of "Mon, 1 Feb 2010 17:50:04 -0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org Luiz Capitulino writes: > On Mon, 01 Feb 2010 20:37:41 +0100 > Markus Armbruster wrote: > >> Luiz Capitulino writes: >> >> > On Mon, 01 Feb 2010 18:08:27 +0100 >> > Markus Armbruster wrote: [...] >> >> I don't doubt your design does the job. I just think it's overly >> >> general. I had something far more stupid in mind: >> >> >> >> client connects >> >> server -> client: version & capability offer (one message) >> >> again: >> >> client -> server: capability selection (one message) >> >> server -> client: either okay or error (one message) >> >> if error goto again >> >> connection is now ready for commands >> >> >> >> No modes. The distinct lack of generality is a design feature. >> > >> > I like the simplicity and if we were allowed to change later I'd >> > do it. >> > >> > The question is if we will ever want features to be _configured_ >> > before the protocol is operational. In this case we'd need to >> > pass feature arguments through the capability selection command, >> > which will get ugly and hard to use/understand. >> > >> > Mode oriented support doesn't have this limitation. Maybe we >> > won't never really use it, but it's safer. >> >> Capability selection could be done as an object where the name/value >> pairs are capability/argument. If you need multiple arguments for a >> capability, make the capability's value an object. > > That's exactly what seems complicated to me, because besides performing > two functions (enable/configure) some feature setup could require > more commands to be done in a clear way. What do you mean by "feature setup"? And how does it go beyond setting a bunch of parameters? > The async messages setup in the previous series was an example of this. I don't remember the details. Could you summarize? > As said we might never use this, but I wouldn't like to regret later. A somewhat plausible example for how it could be needed would help.