From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48920 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyVe5-0001Q7-2G for qemu-devel@nongnu.org; Sat, 12 Mar 2011 15:42:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PyVe3-0001Ve-OQ for qemu-devel@nongnu.org; Sat, 12 Mar 2011 15:42:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PyVe3-0001VT-EV for qemu-devel@nongnu.org; Sat, 12 Mar 2011 15:42:39 -0500 Message-ID: <4D7BDAB9.2030800@redhat.com> Date: Sat, 12 Mar 2011 22:42:33 +0200 From: Avi Kivity 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> <4D78F678.9070406@codemonkey.ws> In-Reply-To: <4D78F678.9070406@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 03/10/2011 06:04 PM, Anthony Liguori wrote: > 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. It would be much better to avoid introducing deprecated commands. They're a maintenance burden for both server and client, and a testing burden as well. I feel it's better to spend more time to get something we truly like. > >> >>> 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. I note that connect is not protocol level (i.e. execute: connect, signal: io-error instead of connect; io-error). Regarding class hinting, I don't object to that, but I feel that the schema provides all of the benefits already. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.