Consumability of vdsm via libvdsm.so

[Saggi Mizrahi]

I have an Idea, having json rpc for the over HTTP and 2 way json RPC over openstacks' messaging abstraction layer.

This means we have 1 actual code base, the interfaces are on the transport layer.
And if you choose to use messaging you (in the future) get 2 way communication which means we can use.
Json-RPC notification for events. And that we (in the future) might fit to an openstack cluster.

I still think generating the java bindings is preferable as it will have to be done and having it generated straight from the schema is ideal.


----- Original Message -----
> From: "Adam Litke" <agl at us.ibm.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: "Saggi Mizrahi" <smizrahi at redhat.com>, arch at ovirt.org
> Sent: Tuesday, August 14, 2012 10:09:28 AM
> Subject: Re: Consumability of vdsm via libvdsm.so
> 
> On Mon, Aug 13, 2012 at 04:54:18PM -0400, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Yaniv Kaul" <ykaul at redhat.com>
> > > > To: "Adam Litke" <agl at us.ibm.com>
> > > > Cc: arch at ovirt.org
> > > > Sent: Monday, August 13, 2012 11:49:21 AM
> > > > Subject: Re: Consumability of vdsm via libvdsm.so
> > > > 
> > > > 
> > > > 
> > > > On 08/13/2012 06:21 PM, Adam Litke wrote:
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > We just finished a lively discussion regarding the ongoing
> > > > effort
> > > > to
> > > > stabilize
> > > > the vdsm API using a C library called libvdsm.  There are many
> > > > things
> > > > that need
> > > > discussion, but I would like to focus this thread on one in
> > > > particular:
> > > > 
> > > > Can ovirt-engine consume libvdsm via JNI?
> > > > 
> > > > libvdsm provides a full-featured C interface to the vdsm API
> > > > using
> > > > GObject.
> > > > Java bindings are provided automatically by jGIR[1].  The
> > > > library
> > > > communicates
> > > > with vdsmd using an internal transport which is not exposed to
> > > > end
> > > > users
> > > > (including ovirt-engine).  I would like to learn from folks
> > > > with
> > > > deep
> > > > Java
> > > > knowledge if this approach is workable.  What are the technical
> > > > challenges to
> > > > integrating in this way?  Please save discussion of AMQP and
> > > > other
> > > > bindings for
> > > > other threads.
> > > > 
> > > > Thanks!
> > > > 
> > > > [1] https://live.gnome.org/JGIR
> > > > How mature/maintained is JGIR?
> > > > Last commit seems to be 2010-02-09.
> > > > The author is: Alexander Kurtakov <akurtako at redhat.com>
> > > > His status in our organizational chart:
> > > > Employee Type: Ex-employee
> > > It will need some work to get it up to par with the rest of the
> > > gobject generators
> > 
> > It's been dead since 2009, that doesn't seem very promising
> > (http://www.ohloh.net/p/java-gobject-introspection)
> > 
> > It also states: "It also includes a custom GLib/GObject interface
> > layer adapted from gstreamer-java." and looking at gstreamer-java
> > yields: "An unofficial/alternative set of java bindings for the
> > gstreamer multimedia framework"
> > 
> > Again, doesn't look like something you want to base your API on.
> > Sounds to me like the 'free' java bindings come at a very high cost
> > (bringing JGIR up to date and maintaining it).
> > 
> > What are the alternatives?
> 
> There are two other alternatives (and one bad idea) that come to
> mind:
> 
> 1.) Generate our own Java bindings to libvdsm.so during the vdsm
> build process.
> 
> I prefer this option from an API cleanliness POV because the
> transport code
> would only be written once (in libvdsm.so).  This form of generation
> should be
> simple because we are just wrapping the library so it can be called
> via JNI.
> 
> 
> 2.) Generate a native Java "library" that is equivalent to
> libvdsm.so.
> 
> This gets us into the business of libvirt-style bindings generation
> which I
> think is a mistake.  It opens the door to us maintaining parallel
> implementations of "libvdsm"s (one per language).
> 
> 
> -1.) Standardize the transport around JSON-RPC and make that the
> supported
> interface.
> 
> I am only mentioning it because I am certain someone will bring it
> up.  I think
> it's a bad idea and it's off-topic for this particular thread anyway.
> 
> --
> Adam Litke <agl at us.ibm.com>
> IBM Linux Technology Center
> 
>