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:
- 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 [1]. 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.
- 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 :)
[1] http://git.qemu.org/?p=qemu.git;a=blob;f=qapi-schema.json;h=3b6e3468b440b4b6... [2] http://fpaste.org/rt96/
Probably more than you bargained for when asking for more info... :)
Indeed!
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 published schema.
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 dispatch in languages like python, perl, javascript, or full auto-generation 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.
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!