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.
There is a schema describing the fields (name, size, number of elements), but their types (int, buffer, sub-field, array of X) are derived from the JSON objects (ie. the JSON parser does this job). > > 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. What clients do you have in mind? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
