On 06/27/2012 05:38 PM, Ayal Baron wrote:
----- 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.
libvdsm would keep XML-RPC support--not VDSM itself.
IOW, libvdsm would need enough XML-RPC support to talk to old versions of VDSM.
That doesn't mean libvdsm needs to expose ever possible thing that's in the
current XML-RPC interface.
Regards,
Anthony Liguori
>
> 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
>>>
>
>