----- Original Message -----
> From: "Adam Litke" <a...@us.ibm.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>
> Cc: "Anthony Liguori" <anth...@codemonkey.ws>, "VDSM Project Development" 
> <vdsm-devel@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.
> 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 <a...@us.ibm.com>
> IBM Linux Technology Center
vdsm-devel mailing list

Reply via email to