On 06/27/2012 05:13 PM, Ayal Baron wrote:
----- 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.
And I'm suggesting is to make the C bindings the supported interface and make
the wire protocol an implementation detail.
You could then implement the C bindings (using GObject or whatever) via the
XML-RPC transport if you liked.
It also presents a better integration story as you could more easily expose the
VDSM API as part of a large CIM/AMQP model data model if you like.
Regards,
Anthony Liguori
>
> ----- 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
>