From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38244 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxiLT-0000rZ-UK for qemu-devel@nongnu.org; Thu, 10 Mar 2011 11:04:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxiLS-0001zW-G2 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 11:04:11 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:45002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxiLS-0001zR-DN for qemu-devel@nongnu.org; Thu, 10 Mar 2011 11:04:10 -0500 Received: by gwb19 with SMTP id 19so579840gwb.4 for ; Thu, 10 Mar 2011 08:04:09 -0800 (PST) Message-ID: <4D78F678.9070406@codemonkey.ws> Date: Thu, 10 Mar 2011 10:04:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <1299460984-15849-20-git-send-email-aliguori@us.ibm.com> <4D778117.9060505@redhat.com> <4D778545.7040403@codemonkey.ws> <4D778797.9090602@redhat.com> <4D778E07.5070408@codemonkey.ws> <4D78C69F.6010003@redhat.com> <4D78DC5A.3000601@codemonkey.ws> <4D78DF3A.9000600@redhat.com> <4D78EF67.4060009@codemonkey.ws> <4D78F207.70306@redhat.com> In-Reply-To: <4D78F207.70306@redhat.com> 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: Avi Kivity Cc: qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 03/10/2011 09:45 AM, Avi Kivity wrote: >> >>> btw2, I now nominate subscribe and unsubscribe as replacements for >>> get and put. >> >> Subscribe implies sub/pub in my mind and we're not publishing events >> so I don't think it fits the model. >> >> A pub/sub event model would be interesting to think through but >> without a global namespace and object model, I don't think we can >> make it fit well. > > I feel we're still not communicating. What does 'get-*-event' mean? > > I think you're using some nomenclature that is unfamiliar to me. No, I'm just defending something that I think fundamentally sucks. I very purposefully am trying to avoid heavy protocol visible changes at this stage. The only reason I added signal accessors is that the current event model is unusable from a C API. I am in full agreement that the current signal model needs to be rethought and should be changed at the protocol level. I just don't want to do that right now because there are a ton of internal improvements that can be made by without doing that. The signal accessors are ugly but they're just a handful of commands that can be deprecated over time. We should revisit events but we should take the time to design it and plan for a protocol addition for 0.16. > >> That's why I'm using signal/slots. It's much more conducive to a >> procedural model. > > I still don't follow. We have a connection, over which we ask the > other side to let us know when something happens, then that other side > lets us know when it happens, then we ask it to stop, then it stops. > There are no signals or slots anywhere. If there are in the code, > let's not mix it up with the protocol. Dropping my legacy baggage, here's what I'd like to see us do from a protocol perspective. I'd like to first introduce class hinting and switch all of the string handles that we use today to class handles. So: { execute: query-block } { return: [ { __jsonclass__: 'BlockDevice', id=ide0-hd0 }, { __jsonclass__: 'BlockDevice', id=ide1-cd0 } ] } { execute: connect, arguments: { 'obj': { __jsonclass__: BlockDevice, id=ide0-hd0 }, 'signal': 'io-error' } } { return: { __jsonclass__: Connection, id=1 } } { signal: 'io-error', connection: { __jsonclass__: Connection, id=1 }, arguments: { action='stop', ... } } { execute: disconnect, arguments: { 'connection': { __jsonclass__: Connection, id=1 } } } { return: null } The advantages here are many. You get much stronger typing in C. If the schema is done right, it trivially maps to an object model in Python. Regards, Anthony Liguori >>> That makes a C centric wire protocol. Clients don't have to be C. >> >> But a C client is by far the most important of all clients--QEMU. If >> we use QMP extensively internally, then we guarantee that the API is >> expressive and robust. > > No, internally we have the most scope to fix mistakes. > >> >> If we build the API only for third-party clients, we end up with >> pretty much what we have today. An API with good intentions but >> that's more or less impossible to use in practice. > > Or we have something that's nice for C but hard to use or inconsistent > with whatever language a management client is written in. >