From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LryFH-0006tt-9j for qemu-devel@nongnu.org; Thu, 09 Apr 2009 13:40:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LryFC-0006mt-Fs for qemu-devel@nongnu.org; Thu, 09 Apr 2009 13:40:58 -0400 Received: from [199.232.76.173] (port=36522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LryFC-0006ma-4a for qemu-devel@nongnu.org; Thu, 09 Apr 2009 13:40:54 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]:33380) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LryFB-00054y-EU for qemu-devel@nongnu.org; Thu, 09 Apr 2009 13:40:53 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n39HbaZ6004276 for ; Thu, 9 Apr 2009 13:37:36 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n39HepJ1179770 for ; Thu, 9 Apr 2009 13:40:51 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n39HeoMX016115 for ; Thu, 9 Apr 2009 13:40:50 -0400 Message-ID: <49DE3321.4090900@us.ibm.com> Date: Thu, 09 Apr 2009 12:40:49 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <49DDAF9F.7040400@redhat.com> <49DDF807.1050707@us.ibm.com> <49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com> <49DE0042.9050103@redhat.com> <49DE0271.8090103@us.ibm.com> <49DE05F2.5060304@redhat.com> <49DE0673.3070501@us.ibm.com> <49DE081D.1030702@redhat.com> <49DE0CF2.3060307@us.ibm.com> <49DE1029.3030909@redhat.com> <49DE16DE.6030206@us.ibm.com> <49DE1AD2.2060600@redhat.com> <49DE1DB3.30402@us.ibm.com> <49DE229B.7050408@redhat.com> <49DE2580.2030507@us.ibm.com> <49DE29C5.6010601@redhat.com> In-Reply-To: <49DE29C5.6010601@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard Avi Kivity wrote: > (qemu) notify vnc on > > ... time passes, we want to allow members of group x to log in > > (qemu) vnc_set_acl group:x > OK > (qemu) > notification: vnc connect aliguori > (qemu) > > with a single monitor, we can be sure that the connect happened the > vnc_set_acl. If the notification arrives on a different session, we > have no way of knowing that. Only because there isn't a time stamp associated with the completion of the other monitor command. And you can globally replace timestamp with some sort of incrementing id that's associated with each notification and command completion. You'll need this to support multiple monitors even with your model. IMHO, multiple monitors is a critical feature to support in the long term. >> I expect that in the short term future, we'll have a non-human >> monitor mode that allows commands to be asynchronous. > > Then let's defer this until then? 'wait' is not useful for humans, > they won't be retyping 'wait' every time something happens. But wait is useful for management apps today. A wait-forever, which is already in the next series, is also useful for humans. It may not be a perfect interface, but it's a step in the right direction. We have time before the next release and I expect that we'll have a non-human mode before then. >> What's the established practice? Do you know of any protocol that is >> line based that does notifications like this? > > I guess most MUDs? I've never used a MUD before, I think that qualifies as before my time :-) >> >> IMAP IDLE is pretty close to "wait-forever". > > IMAP IDLE can be terminated by the client, and so does not require > multiple sessions (though IMAP supports them). Most modern clients use multiple sessions. If you look at IMAP, it doesn't multiplex commands so multiple sessions are necessary to maintain usefulness while performing a long running task. Anyway, I think terminating a wait is a perfectly reasonable requirement. Regards, Anthony Liguori