On Tue, 13 Jul 2010 10:30:24 -0300 Miguel Di Ciurcio Filho <miguel.fi...@gmail.com> wrote:
[...] > On Tue, Jul 13, 2010 at 8:49 AM, Markus Armbruster <arm...@redhat.com> wrote: > >> +- "properties": a list where each element is an json-object that > >> describes a > >> + property of the device. Each json-object contains the following: > >> + - "name": the name of the property (json-string) > >> + - "type": a json-object that contains the following: > >> + - "qdev": the internal name of the type of the property > >> (json-string) > >> + - Possible values: uint8, uint16, uint32, uint64, int32, > >> macaddr, > >> + drive, chr, string, netdev, bit, taddr > >> + - "qmp": the json equivalent type of the internal type > >> (json-string) > >> + - Possible values: integer, string, boolean > > > > Fairly close to JSON Schema, but there are differences. > > > > Do we need "qdev"? Is exposing it wise? Smells a bit too much of > > internal detail for comfort... > > > > Could we use "type" just like JSON Schema? Drop "qdev" or move it out > > of "type", then make "type" what its member "qmp" is now. > > > > 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. > > 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.