Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2)

[Anthony Liguori]

On 03/16/2011 02:27 PM, Luiz Capitulino wrote:
> > You can design interfaces in Python that rely on variant arrays or
> > types, or that add keyword values to arguments, but the absence of those
> > does not make a Bad Library in Python.
> >
> > This has nothing to do with the need for bindings.
> I mentioned bindings because you put so much emphasis on C consumers
> that sometimes I wonder if all you want is libqmp and libqmp only.

The transports (libqmp and QMP) are less important than the interface 
itself.  My emphasis is on the API, not the transports or 
materialization of it.

The terminology gets confusing and I probably am not consistent enough 
in how I use it.

> > The need for
> > bindings is entirely based on whether the RPC being used is
> > self-describing.  JSON is.
> >
> > That said, I think we made a critical mistake in QMP that practically
> > means that we need bindings for QMP.  There is no argument ordering.
> I'm sorry? Critical mistake? Didn't _we_ consciously choose a dictionary
> for this?

Yes, we did.  In fact, I'm fairly sure that Avi and/or I strongly 
advocated it.

But hindsight is always 20/20 and if our goal is to have an API that 
doesn't require special support in Python beyond a simple transport 
class, using dictionaries and not allowing unnamed positional parameters 
was a mistake.

But we makes lots of mistakes.  That's part of the development process.

> > So
> > I can write a Python class that does:
> >
> > import qmp
> >
> > qmp.eject_device(device='ide0-hd0')
> >
> > But I cannot write a library today that does:
> >
> > qmp.eject_device('ide0-hd0')
> >
> > Without using a library that has knowledge of the QMP schema.  This is
> > somewhat unfortunate and I've been thinking about adding another code
> > generation mode in qmp-gen.py to generate wrappers that would enable the
> > more natural usage in Python.
> I don't get it. Having knowledge of the schema is needed anyway, isn't it?

If we allowed positional arguments, it wouldn't be needed.  For 
instance, with xmlrpclib in python, you can do:

srv = ServerProxy('http://localhost:8000/RPC2')
srv.eject_device('ide0-hd0')

And it Just Works.  The transport doesn't have to know anything about 
the schema because the server does all of the parameter validation.

We could fix this by adding another way of specifying unnamed parameters 
in QMP.  Something like:

import qmp

srv = qmp.ServerProxy('/tmp/qmp.sock')
srv.eject_device('ide0-hd0')

Becomes:

{ 'execute': 'eject_device', 'ordered_arguments': [ 'ide0-hd0' ], 
arguments: {} }

I'm not sure it's really worth it though.  I don't think it's a terrible 
thing for us to generate a Python consumable schema.  I don't think it's 
all that important for us to worry about QMP as an RPC mechanism being 
consumable outside of QEMU which means that we can (and should) be 
providing high level language libraries for it.

> > > Also, what's the problem with C consumers using QMP? Libvirt is C, and it
> > > does it just fine.
> > I was going to cut and paste libvirt's code that handles query-pci to
> > show you how complex it is to use vs. just using libqmp
> Does this suggest you think libvirt should switch from QMP to libqmp?

I think they eventually should, yes.  Why duplicate all of the 
marshalling and unmarshalling code unnecessarily especially when dealing 
with complex data structures?

> And, if you don't want to focus on non-C consumers, why having QMP at all?
> (I'm *not* saying I'm ok in dropping it).

No matter what, we need an RPC.  You can't drop QMP because something 
needs to take it's place.

The question is whether we expect projects to write directly to the 
protocol or use libraries provided by use to handle it.  I don't think 
it's practical to expect everyone to write directly to the protocol 
(particularly when dealing with C).

> > but it turns out
> > libvirt doesn't implement query-pci in QMP mode and falls back to the
> > human monitor.  I think that might be as good of a way to show my point
> > though :-)
> This comment assumes two things: 1. query-pci is good in its current form,

I think it's one of our better commands actually.

> 2. libvirt doesn't use it because it's complex.
>
> We already had changes proposal to query-pci and I can't tell why libvirt
> doesn't use it. If it's because it's complex, then we need to know why it's
> complex: is it the command or is it accessing JSON from C?

It returns a complex data structure.  There's nothing wrong with that, 
but it's very hard to interface with at the JSON level.  Is there really 
any doubt about that?

> > > > If we add a field to a structure,
> > > > as long as we use feature flags (we do), only the places that care to
> > > > set that field need to worry about it.
> > > Why do we need this in an internal interface?
> > It's about eating our own dog food.  It helps us ensure that we're
> > really providing high quality external interfaces.
> We'll be eating our food just fine by using the internal interface
> as an internal interface.

What I struggle with it what it means for you to say that libqmp is an 
internal interface.  libqmp is a C library that implements QMP.  QEMU 
would never use libqmp directly (it doesn't need to).  If it cannot 
maintain a stable ABI, than that means it's impossible to write a QMP 
client that maintains a stable C ABI unless you totally redefine the 
interfaces.

Is that really desirable?

Regards,

Anthony Liguori

> > Regards,
> >
> > Anthony Liguori