qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Wed, 24 Jun 2009 14:02:14 +0100
User-agent: Mutt/1.4.1i

On Wed, Jun 24, 2009 at 07:46:04AM -0500, Anthony Liguori wrote:
> Vincent Hanquez wrote:
> >On Tue, Jun 23, 2009 at 05:50:24PM -0500, Anthony Liguori wrote:
> >  
> >>>this one is mentioned on the website and has been changed recently (may 
> >>>2009):
> >>>
> >>>http://fara.cs.uni-potsdam.de/~jsg/json_parser/
> >>>  
> >>>      
> >>That's not a jsonrpc library, that's just a json parser.
> >>    
> >
> >but this is completly trivial at this point. jsonrpc is a json message put 
> >in a
> >certain way.
> >
> >now providing there was a maintained library out there, would you use it ?
> >or do you have more concerns that were unanswered ?
> 
> There are two questions to resolve.  The first is whether we should 
> continue with the current direction (line-based protocol) or whether we 
> should switch to an RPC.  The second question is which RPC we should use.
> 
> I'm not at all convinced that we should switch to an RPC mechanism in 
> the first place.  Perhaps someone could summarize the advantages of 
> doing this because right now, I don't see many.

It really depends what you consider the purpose of the monitor to be.
If the monitor is the "API" application developers use for management,
then a full blown RPC mechaism makes sense. If the monitor is an
internal control mechanism, to enable the building mgmt tools, then
RPC is overkill. I consider QEMU's monitor to be the latter, and 
interface for a single application to use (and developer debugging). 
If we try to turn the monitor into the general end-app developer mgmt
interface, then you open the floodgates to vastly more functionality 
being pushed into the QEMU codebase. I don't think we want that, QEMU
should be lean & mean, and if you want fancy RPC systems then do it in
a tool layered above, be it libvirt, XenD, a CIM agent, or something 
else.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]