On 2012-6-27 0:18, Adam Litke wrote:
On Tue, Jun 26, 2012 at 04:47:35PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 26, 2012 at 05:37:26PM +0300, Dan Kenigsberg wrote:
On Mon, Jun 25, 2012 at 04:19:28PM -0500, Adam Litke wrote:
1) Completely define the current XMLRPC API including all functions, parameters,
and return values. Complex data structures can be broken down into their basic
types. These are: int, str, bool, list, dict, typed-dict, enum. I have already
started this process and am using Qemu's QAPI schema language. You can see that
here . For an example of what that looks like describing the vdsm API see
this snippet .
2) Import the parser/generator code from qemu for the above schema. Vdsm will
require a few extensions such as typed-dictionaries, tuples, and type aliases.
Adapt the generator so that it can produce a libvdsm which provides API language
bindings for python, c, and java.
3) Implement a vdsm shell in terms of libvdsm. In fact, this can be largely
auto-generated from the schema and accompanying documentation. This can serve
to model how new transports can be written. For example, an AMQP implementation
can be implemented entirely outside of the vdsm project if we wished. It only
needs to talk to vdsm via libvdsm.
Easy as 1,2,3 :)
Probably more than you bargained for when asking for more info... :)
I am still at a loss why the languages take such a prominent place in
your choice for an API. A good API is easily consumable by any language.
I think you are both right here. A good API is easily consumed from any
language, but this doesn't mean there is zero cost to starting to consume
it from a client. You either way to be able to auto-generate code for the
client side APIs in all your languages of choice, or even better, you want
the client side APIs to be just do runtime dynamic dispatch based on
Thanks for commenting! On one hand, dynamic dispatch seems attractive but I
think dramatically increases complexity on both the client and server sides.
Does anyone know of a prominent open source project that has been successful
with dynamic dispatch? I am inclined to go with the C library approach because
it is tried and tested and it fits the model of other virtualization libraries
that I am familiar with.
If you go down the route of writing a C based libvdsm for VDSM, then my
recommendation would be to use the GObject APIs. You can then take full
advantage of the GObject Introspection capabilities to have full dynamic
of code in Vala, C#, etc
Ahh, thanks for reminding me of this. GObject definitely seems like the way to
go. I assume there are no real implications for the schema definition and that
the heavy-lifting for GObject support would be limited to the C code generator.
Time to take a closer look at the GObject stuff.
Even if we can generate the various API bindings from the schema, we
still need to change the transportation layers to connect the new APIs
from the client to the VDSM services, whether or not the layer is
XMLRPC, REST or any other way. I really hate to change the
transportation layer from time to time to know new APIs. It is better
to let the transportation layer to figure out the new API automatically
and keep zero change with new APIs.
I certainly wouldn't waste time writing your own code-generator for all
the various languages, since that's just reinventing the wheel that
GObject Introspection already provides for the most part.
Agreed. I would love to avoid this!
Shu Ming <shum...@linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
vdsm-devel mailing list