On 06/27/2012 05:13 PM, Ayal Baron wrote:

----- Original Message -----
The idea of having a supported C API was something I was thinking
about doing (But I'd rather use gobject introspection and not schema
But the problem is not having a C API is using the current XML RPC
API as it's base

The current XML-RPC API contains a lot of decencies and
inefficiencies and we would like to retire it as soon as we possibly
can. Engine would like us to move to a message based API and 3rd
parties want something simple like REST so it looks like no one
actually wants to use XML-RPC. Not even us.

I do think that having C supportability in our API is a good idea,
but the current API should not be used as the base.

The current API is irrelevant, we should focus on the API we will deliver for 
Fedora 18 / RHEL 7.
I also really don't see what xmlrpc has to do with it.  We specifically 
separated the transport from the API and the c bindings should have nothing to 
do with xmlrpc.

And I'm suggesting is to make the C bindings the supported interface and make the wire protocol an implementation detail.

You could then implement the C bindings (using GObject or whatever) via the XML-RPC transport if you liked.

It also presents a better integration story as you could more easily expose the VDSM API as part of a large CIM/AMQP model data model if you like.


Anthony Liguori

----- Original Message -----
From: "Anthony Liguori"<anth...@codemonkey.ws>
To: "VDSM Project Development"<vdsm-devel@lists.fedorahosted.org>
Cc: "Adam Litke"<a...@us.ibm.com>, "Saggi Mizrahi"
Sent: Monday, June 25, 2012 10:18:33 AM
Subject: [RFC] An alternative way to provide a supported interface
-- libvdsm


I've been reading through the API threads here and considering the
options.  To
be honest, I worry a lot about the scope of these discussions and
that there's a
tremendous amount of work before we have a useful end result.

I wonder if we can solve this problem by adding another layer of

As Adam is currently building a schema for VDSM's XML-RPC, we could
use the QAPI
code generators to build a libvdsm that provided a programmatic C
interface for
the XML-RPC interface.

It would take some tweaking, but this could be made a supportable C
The rules for having a supportable C interface are basically:

1) Never change function signatures

2) Never remove functions

3) Always allocate structures in the library and/or pad

4) Only add to structures, never remove or reorder

5) Provide flags that default to zero to indicate that
fields/features are not

6) Always zero-initialize structures

Having a libvdsm would allow the transport to change over time w/o
end-users.  There are lots of good tools for documenting C APIs and
dealing with
versioning of C APIs.

While we can start out with a schema-generated API, over time, we
libvdsm in an open-coded fashion allowing old APIs to be
reimplemented in terms
of new APIs.

  From a compatibility perspective, libvdsm would be fully backwards
with old versions of VDSM (so it would keep XML-RPC support
but may
require new versions of libvdsm to talk to new versions of VDSM.
  That would
allow for APIs to be deprecated within VDSM without breaking old

I think this would be an incremental approach to building a
supportable API
today while still giving the flexibility to make changes in the

And it should be fairly easy to generate a JNI binding and also
ovirt-engine to use an interface like this (since it already uses


Anthony Liguori

vdsm-devel mailing list

vdsm-devel mailing list

Reply via email to