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 generation)
But the problem is not having a C API is using the current XML RPC API as it's 

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.

----- Original Message -----
> From: "Anthony Liguori" <>
> To: "VDSM Project Development" <>
> Cc: "Adam Litke" <>, "Saggi Mizrahi" <>
> Sent: Monday, June 25, 2012 10:18:33 AM
> Subject: [RFC] An alternative way to provide a supported interface -- libvdsm
> Hi,
> 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
> abstraction...
> 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
> interface.
> 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
> present.
> 6) Always zero-initialize structures
> Having a libvdsm would allow the transport to change over time w/o
> affecting
> 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 can
> implement
> 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
>  compatible
> with old versions of VDSM (so it would keep XML-RPC support forever)
> 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
> clients.
> I think this would be an incremental approach to building a
> supportable API
> today while still giving the flexibility to make changes in the long
> term.
> And it should be fairly easy to generate a JNI binding and also port
> ovirt-engine to use an interface like this (since it already uses the
> Regards,
> Anthony Liguori
vdsm-devel mailing list

Reply via email to