----- 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 > 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.
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. > > ----- 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
