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 [1]. For an example of what that looks like describing the vdsm API > > see > > this snippet [2]. > > > > 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 :) > > > > [1] > > http://git.qemu.org/?p=qemu.git;a=blob;f=qapi-schema.json;h=3b6e3468b440b4b681f321c9525a3d83bea2137a;hb=HEAD > > [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. 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 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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
