From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2R4A-0006Yw-Fp for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:42:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2R42-0000Mq-2l for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:42:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2R41-0000Mb-RE for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:42:14 -0500 Date: Tue, 28 Feb 2012 14:41:42 -0300 From: Luiz Capitulino Message-ID: <20120228144142.71dd6641@doriath.home> In-Reply-To: <20120228170938.GC2725@illuin> References: <2c332c139b3d6b38e2ef93e2efc951f8565c4a52.1329649806.git.mprivozn@redhat.com> <20120223122034.728c259c@doriath.home> <4F4BD034.5030400@redhat.com> <20120228020728.GB2725@illuin> <20120228112222.31482e44@doriath.home> <20120228170938.GC2725@illuin> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Michal Privoznik , qemu-devel@nongnu.org On Tue, 28 Feb 2012 11:09:38 -0600 Michael Roth wrote: > On Tue, Feb 28, 2012 at 11:22:22AM -0300, Luiz Capitulino wrote: > > On Mon, 27 Feb 2012 20:07:28 -0600 > > Michael Roth wrote: > > > > > What about something like this instead: > > > > > > { 'enum': 'GuestIpAddressType', > > > 'data': [ 'ipv4', 'ipv6' ] } > > > > > > { 'type': 'GuestIpAddress', > > > 'data': {'ip-address': 'str', > > > 'ip-address-type': 'GuestIpAddressType', > > > 'prefix': 'int'} } > > > > > > { 'type': 'GuestNetworkInterface', > > > 'data': {'interface': {'name': 'str', > > > '*hardware-address': 'str', > > > '*ip-addresses': ['GuestIpAddress'] } } } > > > > > > { 'type': 'GuestNetworkInfo', > > > 'data': { 'interfaces': ['GuestNetworkInterfaces'] } } > > > > > > { 'command': 'guest-network-info', > > > 'returns': 'GuestNetworkInfo' } > > > > > > In the future we might have: > > > > > > { 'type': 'GuestNetworkInfo', > > > 'data': { 'interfaces': ['GuestNetworkInterfaces'], > > > 'routes': ['GuestNetworkRoute'], > > > 'bridges': ['GuestNetworkBridge'], > > > 'firewall-rules': ['firewall-rule'], # yikes > > > etc. } } > > > > Both approaches are fine to me, but another possibility is to split this into > > multiple commands, like guest-interfaces-info, guest-routes-info etc. This would > > allow for simpler commands with less clutter. > > Hmm, I know Michal already sent a new version with my suggestions, but > you're right, splitting out the commands simplified both the responses, > and makes it easier to discover whether or not that information is > available, since you can look for the command in guest-info before > attempting it, rather than attempting it and then looking at the result. > > So maybe just something this?: > > { 'type': 'GuestNetworkInterface', > 'data': { 'name': 'str', > '*hardware-address': 'str', > '*ip-addresses': ['GuestIpAddress'] } } } > > { 'command': 'guest-network-interfaces', > 'returns': ['GuestNetworkInterface'] } Looks good to me, the only nitpick is that I think command names should be verbs.