----- Original Message -----
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.
Sounds good then.
Your previous comment:
>>> From a compatibility perspective, libvdsm would be
fully
>>> backwards
>>> compatible
>>> with old versions of VDSM (so it would keep XML-RPC support
>>> forever)
Threw me off there as we would not want to keep on supporting XML-RPC.
What's more, the current API has way too many things that have to go so needing to
keep those would just be sad and painful.
>
> 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
> >>
>
>