Re: [Qemu-devel] Re: [PATCH 01/10] Introduce qmisc module

[Vincent Hanquez <vincent@snarc.org>]

Anthony Liguori wrote:
> Vincent Hanquez wrote:
>> I can't think of any reason why integration with qobject would take 
>> more than 50 lines of C on the user side of the library.
>> since the API is completely SAX like (i call it SAJ for obvious 
>> reason), you get callback entering/leaving object/array
>> and callback for every values (string, int, float, null, true, false) 
>> as a char * + length. for exactly the same reason, integration with 
>> glib would take the same 50 lines "effort".
>>
>> note that FTR, obviously i'ld like to have my library used, but i'm 
>> happy that any library that is *fully* JSON compliant is used (no 
>> extensions however since you're obviously loosing the benefit of 
>> using JSON if you create extensions).
>
> We need two sets of extensions for use within qemu.  Single quoted 
> strings and varargs support.  While single quoted strings would be 
> easy to add to any library, vararg support is a bit more tricky as you 
> need to carefully consider where you pop from the varargs list.  A 
> simple sprintf() isn't sufficient for embedding QObjects.
care to explain what's a single quoted string and varargs support means 
in your context ? (just a simple example you do maybe ?)
> When generating on-the-wire response traffic, we shouldn't use any of 
> the extensions so it will be 100% json.org compliant.
great.
> I'm pretty sure if you tried to duplicate the functionality of my 
> patches, it would be much more than 50 lines.  That's not saying it's 
> a better json parser, just that we're looking for very particular 
> features from it.
Since it doesn't appears to be linked to json particularly, I don't 
understand why it's a feature of the parser though.. and then any parser 
could grow the support you need on top of the parser couldn't they ?

-- 
Vincent