On 07/05/2012 04:45 PM, Adam Litke wrote:
On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote:

----- 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.
I am not sure I am ready to conceed that XML-RPC is too slow for our needs.  Can
you provide some more detail around this point and possibly suggest an
alternative that has even lower overhead without sacrificing the ubiquity and
usability of XML-RPC?  As far as the two-way communication point, what are the
options besides AMQP/ZeroMQ?  Aren't these even worse from an overhead
perspective than XML-RPC?  Regarding two-way communication: you can write AMQP
brokers based on the C API and run one on each vdsm host.  Assuming the C API
supports events, what else would you need?
I personally think that using something like AMQP for inter-node communication and engine - node would be optimal. With a rest interface that just send messages though something like AMQP.

Thanks
Robert
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.
That might be true regarding the current in-tree implementation.  However, I can
almost guarantee that someone wanting to write a web GUI on top of standalone
vdsm would want a REST API to talk to.  But libvdsm makes this use case of no
concern to the core vdsm developers.

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
Ok.  Redoubling my efforts to get this done.  Describing the output of
list(True) takes awhile :)



_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to