----- 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" <anthony(a)codemonkey.ws>
> To: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
> Cc: "Adam Litke" <agl(a)us.ibm.com>, "Saggi Mizrahi"
> <smizrahi(a)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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel