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.
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.
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 <agl(a)us.ibm.com>
IBM Linux Technology Center