From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55228 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OYfmK-0000wy-Oc
	for qemu-devel@nongnu.org; Tue, 13 Jul 2010 09:44:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <lcapitulino@redhat.com>) id 1OYfmJ-0003P5-50
	for qemu-devel@nongnu.org; Tue, 13 Jul 2010 09:44:08 -0400
Received: from mx1.redhat.com ([209.132.183.28]:20313)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <lcapitulino@redhat.com>) id 1OYfmI-0003Oz-TS
	for qemu-devel@nongnu.org; Tue, 13 Jul 2010 09:44:07 -0400
Date: Tue, 13 Jul 2010 10:44:00 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] QMP: Introduce the documentation for
	query-qdm
Message-ID: <20100713104400.302e1423@redhat.com>
In-Reply-To: <AANLkTin15Kr-FF2CVb4JMomudM9HzH0tkphqITdG45h6@mail.gmail.com>
References: <1278699228-7665-1-git-send-email-miguel.filho@gmail.com>
	<m3sk3nppnp.fsf@blackfin.pond.sub.org>
	<AANLkTin15Kr-FF2CVb4JMomudM9HzH0tkphqITdG45h6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.nongnu.org/archive/html/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: Miguel Di Ciurcio Filho <miguel.filho@gmail.com>
Cc: avi@redhat.com, Gerd Hoffmann <kraxel@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

On Tue, 13 Jul 2010 10:30:24 -0300
Miguel Di Ciurcio Filho <miguel.filho@gmail.com> wrote:

[...]

> On Tue, Jul 13, 2010 at 8:49 AM, Markus Armbruster <armbru@redhat.com> wr=
ote:
> >> +- "properties": a list where each element is an json-object that desc=
ribes a
> >> + =C2=A0property of the device. Each json-object contains the followin=
g:
> >> + =C2=A0 =C2=A0 - "name": the name of the property (json-string)
> >> + =C2=A0 =C2=A0 - "type": a json-object that contains the following:
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0- "qdev": the internal name of the type o=
f the property (json-string)
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Possible values: uint8, u=
int16, uint32, uint64, int32, macaddr,
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0drive, chr, string, =
netdev, bit, taddr
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0- "qmp": the json equivalent type of the =
internal type (json-string)
> >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Possible values: integer,=
 string, boolean
> >
> > Fairly close to JSON Schema, but there are differences.
> >
> > Do we need "qdev"? =C2=A0Is exposing it wise? =C2=A0Smells a bit too mu=
ch of
> > internal detail for comfort...
> >
> > Could we use "type" just like JSON Schema? =C2=A0Drop "qdev" or move it=
 out
> > of "type", then make "type" what its member "qmp" is now.
> >
>=20
> I think it is better not to expose too much the internals to. My
> initial concern and Daniel's too was to make clear what is the meaning
> of the property. Like, give me a proper formated MAC address or an id
> of a properly created netdev.
>=20
> But I think we could drop the qdev properties stuff and return the
> proper error in case of parsing problems.

Then client writers will have to know how to encode the property ahead of
time, which makes self-documenting useless.