----- 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. +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 <a...@us.ibm.com> > IBM Linux Technology Center > > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
