----- 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"<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

Reply via email to