----- Original Message -----
From: "Adam Litke" <agl(a)us.ibm.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
Cc: "Anthony Liguori" <anthony(a)codemonkey.ws>, "VDSM Project
Development" <vdsm-devel(a)lists.fedorahosted.org>
Sent: Thursday, July 5, 2012 2:34:50 PM
Subject: Re: [RFC] An alternative way to provide a supported interface -- libvdsm
On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
> 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
I want to disect this a bit to find out exactly where there might be
agreement
and disagreement.
C API is a good thing to implement - Agreed.
I also want to use gobject introspection but I don't agree that using
glib
precludes the use of a formalized schema. My proposal is that we
write a schema
definition and generate the glib C code from that schema.
I agree that the _current_ xmlrpc API makes a pretty bad base from
which to
start a supportable API. XMLRPC is a perfectly reasonable
remote/wire protocol
and I think we should continue using it as a base for the next
generation API.
Using a schema will ensure that the new API is well-structured.
There major
problems with XML-RPC (and to some extent with REST as well) are high call overhead and no
two way communication (push events). Basing on XML-RPC means that we will never be able to
solve these issues.
> 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 am proposing that AMQP brokers and REST APIs could be written
against the
public API. In fact, they need not even live in the vdsm tree
anymore if that
is what we choose. Core vdsm would only be responsible for providing
libvdsm
and whatever language bindings we want to support.
If we take the libvdsm route,
the only reason to even have a REST bridge is only to support OSes other then Linux which
is something I'm not sure we care about at the moment.
> 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.
Let's _start_ with a schema document that describes today's API and
then clean
it up. I think that will work better than starting from scratch.
Once my
schema is written I will post it and we can 'patch' it as a community
until we
arrive at a 1.0 version we are all happy with.
+1
If we are going to break compatibility with the current xmlrpc
interface, I
would like to have a commitment from ovirt-engine to support the new
library
interface so that we can drop xmlrpc.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center