On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote:
> I agree apps shouldn't use it for RPC, but admins using the interactive user
> monitor are just as deserving of stable commands & args.
I think, once QMP is completely there, admins would be better using a qemu-cmd
that's just
On Thu, Mar 25, 2010 at 01:59:22PM +, Daniel P. Berrange wrote:
> > From my point of view, i wouldn't want to write a high level management
> > toolstack in C, specially
> > since the API is well defined JSON which is easily available in all high
> > level language out there.
>
> It was pret
On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote:
> Why?
>
> We can provide a generic QMP dispatch interface that high level
> languages can use. Then they can do fancy dispatch, treat QErrors as
> exceptions, etc.
Because more than likely it will be more efforts than doing the
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *ac
On Tue, Nov 03, 2009 at 11:38:18AM +0200, Avi Kivity wrote:
> On 11/03/2009 01:25 PM, Vincent Hanquez wrote:
>> not sure if i'm missing the point here, but couldn't it be hypothetically
>> extended to stuff 3d (or video& more 2d accel ?) commands too ? I can'
On Tue, Nov 03, 2009 at 07:39:34AM +0100, Alexander Graf wrote:
>
> On 03.11.2009, at 07:34, Avi Kivity wrote:
>
>> On 11/03/2009 08:27 AM, Alexander Graf wrote:
>>>
How does it work today?
>>>
>>> You boot into a TERM=dumb line based emulation on 3270 (worst thing
>>> haunting people's nigh
On Fri, Oct 30, 2009 at 05:51:20PM +0100, Paolo Bonzini wrote:
> I'm a bit lost on the QJSON patches that were posted and what's missing
> yet... Anthony, can you place them in your queue or in a separate
> branch?
a bit OOT by now, but my libjson parser/printer is available at
http://projects
On Fri, Oct 30, 2009 at 06:33:15PM +0100, Paolo Bonzini wrote:
> On 10/30/2009 06:15 PM, Daniel P. Berrange wrote:
>> If we're going to use JSON we should be 100% compliant with the JSON
>> spec, not extend it. By adding custom QEMU extensions, we loose the
>> ability for programming language to tr
Anthony Liguori wrote:
Here's a first pass. I'll clean up this afternoon and post a proper
patch. It turned out to work pretty well.
It doesn't seems to validate anything ?? or is it just a lexer ?
you're also including ' as a string escape value (is that the single
quote thing you were talki
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 value
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/arra
Luiz Capitulino wrote:
it got a raw/pretty printer, an interruptible parser (on the same idea
as JSON_parser.c), it's faster than JSON_parser.c [1],
it's completely generic (more like a library than an embedded thing),
fully JSON compliant (got a test suite too), support
user supplied alloc func
Anthony Liguori wrote:
Paolo Bonzini wrote:
On 10/16/2009 11:37 PM, Anthony Liguori wrote:
I already am :-) Stay tuned, I should have a patch later this
afternoon.
Was it a race? (Seriously, sorry I didn't notice a couple of hours
ago).
This one is ~5% slower than the "Evil" one, but h
13 matches
Mail list logo
