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

[Vincent Hanquez <vincent@snarc.org>]

Luiz Capitulino 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".
>>     
>
>  No lines is a lot better than 50. :)
>   
well it all depends on how you see thing; whilst i'm happy to help all 
sort of integration (qemu in this case), my library has been made for 
integrating with absolutely any object model. so 50 lines seems like a 
win to me, because I could do the same thing on a project that use glib, 
or some QT model using exactly the same engine. Hence the reason why i'm 
packaging it as a .a/.so library. (not that I particularly object to an 
embedded use case too).

I think that's a win in the end when people can just reuse wheels 
instead of designing new one for catering for special needs.
>  The real problem though is that the parsers I looked at had their own
> "object model", some of them are quite simple others are more sophisticated
> than QObject. Making no use of any kind of intermediate representation like
> this is a feature, as things get simpler.
>
>  Also, don't get me wrong, but if we would consider your parser we
> would have to consider the others two or three that are listed in
> json.org and have a compatible license.
>   
most of the parser there are either, weirdly licensed, have an object 
model integrated with it, are not interruptible,
or are quite complex for no apparent reason; I carefully read all of 
them, before choosing to reimplement one from scratch.

-- 
Vincent