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 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.
----- Original Message -----
From: "Anthony Liguori" anthony@codemonkey.ws To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Cc: "Adam Litke" agl@us.ibm.com, "Saggi Mizrahi" smizrahi@redhat.com 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:
Never change function signatures
Never remove functions
Always allocate structures in the library and/or pad
Only add to structures, never remove or reorder
Provide flags that default to zero to indicate that
fields/features are not present.
- 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 XML-RPC API).
Regards,
Anthony Liguori