On 05/18/2010 03:27 PM, Markus Armbruster wrote:
Surely the schema has to describe the type as well? If it does, you can
use the schema to generate a classes at compile time.
Doesn't that tie you to a specific version of QMP at compile-time?
The client needs to ignore anything n
Anthony Liguori 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 h
Jan Kiszka writes:
> Avi Kivity wrote:
>> On 05/17/2010 10:57 AM, Jan Kiszka wrote:
>>> 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 distinguis
Jan Kiszka wrote:
> Jamie Lokier wrote:
> > Anthony Liguori wrote:
> >> Instead of encoding just as a string, it would be a good idea to encode
> >> it as something like:
> >>
> >> {'__class__': 'base64', 'data': ...}
> >
> > Is there a benefit to the class indirection, over simply a keyword?:
>
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.
On 05/17/2010 12:17 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 05/17/2010 11:55 AM, Jan Kiszka wrote:
The names of fields are also type information.
Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, tha
Avi Kivity wrote:
> On 05/17/2010 11:55 AM, Jan Kiszka wrote:
>>> The names of fields are also type information.
>>>
>> Not in the case of device_show. The clients have no idea of the vmstate
>> structures before they were transfered. Granted, that will likely remain
>> a special case in the
On 05/17/2010 11:55 AM, Jan Kiszka wrote:
The names of fields are also type information.
Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, that will likely remain
a special case in the QMP command set.
For that
Avi Kivity wrote:
> On 05/17/2010 10:57 AM, Jan Kiszka wrote:
>> 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) y
On 05/17/2010 11:10 AM, Avi Kivity wrote:
Another way of looking at it: if the client sees { __class__: foo, f1:
10, f2: 9 }, it cannot derive any information from __class__ unless it
was aware of foo beforehand. If that's the case, let's make it part
of the schema so it is available at comp
On 05/17/2010 10:57 AM, Jan Kiszka wrote:
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 ty
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 __
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 carr
Avi Kivity wrote:
> On 05/17/2010 03:12 AM, Anthony Liguori wrote:
>> On Sun, May 16, 2010 at 12:38 PM, Jamie Lokier
>> wrote:
>>
>>> Anthony Liguori wrote:
>>>
Instead of encoding just as a string, it would be a good idea to encode
it as something like:
{'__class__': '
Jamie Lokier wrote:
> Anthony Liguori wrote:
>> Instead of encoding just as a string, it would be a good idea to encode
>> it as something like:
>>
>> {'__class__': 'base64', 'data': ...}
>
> Is there a benefit to the class indirection, over simply a keyword?:
>
> {'__base64__': ...}
>
> __clas
On 05/16/2010 01:16 PM, Paolo Bonzini wrote:
On 05/16/2010 11:50 AM, Avi Kivity wrote:
On 05/16/2010 12:37 PM, Paolo Bonzini wrote:
On 05/15/2010 07:31 PM, Avi Kivity wrote:
On 05/15/2010 11:59 AM, Jan Kiszka wrote:
Is this __class__ stuff documented anywhere?
Not yet. Also, we should clar
On 05/16/2010 11:50 AM, Avi Kivity wrote:
On 05/16/2010 12:37 PM, Paolo Bonzini wrote:
On 05/15/2010 07:31 PM, Avi Kivity wrote:
On 05/15/2010 11:59 AM, Jan Kiszka wrote:
Is this __class__ stuff documented anywhere?
Not yet. Also, we should clarify the proposed private extension section
th
Avi Kivity wrote:
> On 05/16/2010 12:37 PM, Paolo Bonzini wrote:
>> On 05/15/2010 07:31 PM, Avi Kivity wrote:
>>> On 05/15/2010 11:59 AM, Jan Kiszka wrote:
> Is this __class__ stuff documented anywhere?
>
Not yet. Also, we should clarify the proposed private extension section
Avi Kivity wrote:
> On 05/15/2010 11:59 AM, Jan Kiszka wrote:
>>
>>> Is this __class__ stuff documented anywhere?
>>>
>>>
>> Not yet. Also, we should clarify the proposed private extension section
>> that only "__some_key" is reserved for downstream, not
>> '__some_other_key__' (i.e. downstre
On 05/16/2010 12:37 PM, Paolo Bonzini wrote:
On 05/15/2010 07:31 PM, Avi Kivity wrote:
On 05/15/2010 11:59 AM, Jan Kiszka wrote:
Is this __class__ stuff documented anywhere?
Not yet. Also, we should clarify the proposed private extension section
that only "__some_key" is reserved for downst
On 05/15/2010 07:31 PM, Avi Kivity wrote:
On 05/15/2010 11:59 AM, Jan Kiszka wrote:
Is this __class__ stuff documented anywhere?
Not yet. Also, we should clarify the proposed private extension section
that only "__some_key" is reserved for downstream, not
'__some_other_key__' (i.e. downstrea
On 05/15/2010 11:59 AM, Jan Kiszka wrote:
Is this __class__ stuff documented anywhere?
Not yet. Also, we should clarify the proposed private extension section
that only "__some_key" is reserved for downstream, not
'__some_other_key__' (i.e. downstream names must not end with '__').
Avi Kivity wrote:
> On 05/15/2010 11:45 AM, Jan Kiszka wrote:
>>
>>> Instead of encoding just as a string, it would be a good idea to encode
>>> it as something like:
>>>
>>> {'__class__': 'base64', 'data': ...}
>>>
>>> We've discussed using hidden properties to describe special things like
>>> abs
On 05/15/2010 11:45 AM, Jan Kiszka wrote:
Instead of encoding just as a string, it would be a good idea to encode
it as something like:
{'__class__': 'base64', 'data': ...}
We've discussed using hidden properties to describe special things like
abstract classes and since we already have this
Anthony Liguori wrote:
> On 05/14/2010 08:20 AM, Jan Kiszka wrote:
>> diff --git a/qjson.c b/qjson.c
>> index 483c667..4d1c21a 100644
>> --- a/qjson.c
>> +++ b/qjson.c
>> @@ -19,7 +19,9 @@
>> #include "qlist.h"
>> #include "qbool.h"
>> #include "qfloat.h"
>> +#include "qbuffer.h"
>> #includ
25 matches
Mail list logo
