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" <[email protected]> > To: "Ayal Baron" <[email protected]> > Cc: "Saggi Mizrahi" <[email protected]>, [email protected] > 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" <[email protected]> > > > > To: "Adam Litke" <[email protected]> > > > > Cc: [email protected] > > > > 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 <[email protected]> > > > > 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 <[email protected]> > IBM Linux Technology Center > > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
