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