From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LsmRL-0002Ui-Q9 for qemu-devel@nongnu.org; Sat, 11 Apr 2009 19:16:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LsmRG-0002OR-Sd for qemu-devel@nongnu.org; Sat, 11 Apr 2009 19:16:47 -0400 Received: from [199.232.76.173] (port=40343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LsmRG-0002OD-I9 for qemu-devel@nongnu.org; Sat, 11 Apr 2009 19:16:42 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59542) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LsmRG-00037I-5l for qemu-devel@nongnu.org; Sat, 11 Apr 2009 19:16:42 -0400 Message-ID: <49E124BB.1010604@redhat.com> Date: Sat, 11 Apr 2009 13:16:11 -1000 From: Zachary Amsden MIME-Version: 1.0 Subject: Re: [libvirt] 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> <49DE3321.4090900@us.ibm.com> <49E0C47F.9070501@redhat.com> In-Reply-To: <49E0C47F.9070501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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, Anthony Liguori , Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard Avi Kivity wrote: > I disagree, I think requiring multiple sessions for controlling a single > application is clumsy. I can't think of one protocol which uses it. I > don't think IMAP requires multiple sessions (and I don't think commands > from one session can affect the other, except through the mail store). I agree, multiple sessions is silly. IMAP uses multiple sessions because the session is stateful, and only one mailbox can be selected, or to do multiple search operations. IMAP servers hate this btw, the number of users per server for IMAP is something like 10x less dense than POP (or at least was years ago when I actually worked on POP and IMAP). >>>> What's the established practice? Do you know of any protocol that >>>> is line based that does notifications like this? I worked on an appliance type server product for a while that had something similar to a monitor control port for issuing all general commands to the machine. The protocol was tagged, line oriented commands, and untagged (*) responses for asynchronous notifications. Bulk data transfers were a bit more complex than they needed to be, as the protocol had a base64 type encoding which required the size to be specified in the transfer command (thus not permitting streaming), but other than that it worked great. ANSI color is also an option to encode and highlight async notices. >>> >>> I guess most MUDs? >> >> I've never used a MUD before, I think that qualifies as before my time >> :-) > > Well I haven't either. Maybe time to start. What? Why have you guys not been using MUDs? I did some development work (obviously not for pay) on a Circle based MUD implementation for a while. Here's an example of mud protocol, showing the prompt... it works over just telnet and is line based with async notifications.. any time a notification comes, it reprints a blank prompt; the client line buffers the input and a better client than telnet would show your entire line. It is highly desirable if you can control and monitor everything from a single telnet session. To share this experience, telnet hrmud.com 4000 ... | 24H 100M 82V > kill fido You tickle the beastly fido as you pierce him. | 24H 100M 82V > The beastly fido tries to bite you but bites his tongue instead! You tickle the beastly fido as you pierce him. The beastly fido is incapacitated and will slowly die, if not aided. | 24H 100M 82V > You tickle the beastly fido as you pierce him. The beastly fido is mortally wounded, and will die soon, if not aided. | 24H 100M 82V > You pierce the beastly fido's heart, you heartbreaker you... The beastly fido is dead! You receive 8 experience points. Your blood freezes as you hear the beastly fido's death cry. | 24H 100M 82V > The green gelatinous blob has arrived. The janitor picks up some trash. | 24H 100M 82V > sacrifice corpse You sacrifice the corpse of the beastly fido.