Anthony Liguori <anth...@codemonkey.ws> writes: > On 05/17/2010 02:45 AM, Avi Kivity wrote: >> On 05/17/2010 10:40 AM, Jan Kiszka wrote: >>> >>>> The alternative is to have a schema. Sun RPC/XDR doesn't carry >>>> any type >>>> information (you can't even distinguish between a number and text) >>>> yet C >>>> clients have to problem extracting typed information from it. >>>> >>>> Having __class__ everywhere means we're carrying the schema in every >>>> message instead of just once. >>> The device_show command is already an example where you don't have a >>> predefined schema. It is derived from the data stream the encodes the >>> vmstate fields. So far we have no collision between base64-encoded >>> buffers and real strings, but this may actually change when we start >>> annotating the fields with symbolic constants. >> >> What is the receiver to do with it? >> >> If it doesn't know the schema (and there is no schema), then all it >> can do is display the key/values. If it does know the schema, then >> __class__ is unnecessary. >> >> My worry is that __class__ will make the protocol more ad-hoc. >> >>> I really don't see the problem with __class__. Being a text protocol, >>> JSON is already fairly verbose. >> >> The problem is not the verbosity, it's that information is carried >> too late. Many clients want to know this information at compile >> time or initialization time, and we are providing it at object >> instantiating time. > > Whether a protocol is self-describing is orthogonal to whether it's > well defined (ala a schema). A self-describing protocol is very > convenient for dynamic languages like Python. We should also provide > a formal schema though for languages that require IDL to generate > bindings (like C).
And that schema should be available over QMP.
