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" <anth...@codemonkey.ws> > To: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > Cc: "Adam Litke" <a...@us.ibm.com>, "Saggi Mizrahi" <smizr...@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: > > 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 > XML-RPC API). > > Regards, > > Anthony Liguori > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
