From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NZmPy-0003Dd-0o
	for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:29:22 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NZmPt-00036I-HU
	for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:29:21 -0500
Received: from [199.232.76.173] (port=43446 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NZmPt-00035m-0y
	for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:29:17 -0500
Received: from mx1.redhat.com ([209.132.183.28]:35252)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <berrange@redhat.com>) id 1NZmPs-0001KW-Hm
	for qemu-devel@nongnu.org; Tue, 26 Jan 2010 09:29:16 -0500
Date: Tue, 26 Jan 2010 14:29:12 +0000
From: "Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
Message-ID: <20100126142912.GN5366@redhat.com>
References: <1264108180-3666-1-git-send-email-lcapitulino@redhat.com>
	<4B59E7C4.2050201@codemonkey.ws>
	<m33a1utfsr.fsf@blackfin.pond.sub.org>
	<20100126095325.23011823@doriath>
	<20100126125754.GA9362@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100126125754.GA9362@shareable.org>
Reply-To: "Daniel P. Berrange" <berrange@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: Markus Armbruster <armbru@redhat.com>, aliguori@us.ibm.com, avi@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On Tue, Jan 26, 2010 at 12:57:54PM +0000, Jamie Lokier wrote:
> Luiz Capitulino wrote:
> > capability_enable [ "foo", "bar" ]
> > 
> >  Now, only one command is not terrible difficult, but we would
> > have to accept an array of objects, like:
> > 
> > [ { "name": "foo", "enabled": true }, { "name": "bar", "enabled": true } ]
> 
> That looks like XML-itis.
> 
> Why not { "foo": true, "bar": true }?

It depends on whether we think we're going to need to add more metadata
beyond just the enabled/disabled status. If we did want to add a further
item against foo & bar, then having the array of hashes makes that 
extension easier becaue you add easily add more key/value pairs to
each.


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|