On Tue, Aug 14, 2012 at 01:43:01PM -0400, Saggi Mizrahi wrote: > > ----- Original Message ----- > > From: "Adam Litke" <[email protected]> > > To: "Saggi Mizrahi" <[email protected]> > > Cc: [email protected], "Ayal Baron" <[email protected]> > > Sent: Tuesday, August 14, 2012 12:36:47 PM > > Subject: Re: Consumability of vdsm via libvdsm.so > > > > On Tue, Aug 14, 2012 at 10:20:34AM -0400, Saggi Mizrahi wrote: > > > I have an Idea, having json rpc for the over HTTP and 2 way json > > > RPC over > > > openstacks' messaging abstraction layer. > > > > So you are proposing to disregard all of the arguments in favor of a > > libvdsm and > > instead standardize on a protocol. In that case, we could just keep > > xmlrpc... > The difference between xml-rpc and json-rpc is that json-rpc is transport > agnostic, less verbose, easier to parse. > > We will be back at square one having every application writing on > > object model > > on top of the transport. We will also need to reinvent a model for > > ensuring > > backwards compatibility of the protocol data." > As I said, I still think we need to have a schema and supply bindings, > GObject for python\C\C++\Vala, and native Java (because, as Yair pointed out, > JNI in Java EE is non standard). > > > > > 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. > > > > In that case we will also need to generate python bindings at a > > minimum. In > > this model, how would REST and AMQP bridges be integrated? > No REST, as I said. We forgo the "everything ever can be supported" for > json-rpc over different transports. HTTP\AMQP\ZMQ\Simple TCP Socket. > Unlike supporting different API schemes supporting transports is fairly > simple because the number of methods to implement is small and remains > constant and is independent of the actual API. > > The big reason to use bindings is to keep us transport agnositc. Something > that REST or SOAP or XML-RPC don't give us because they are bound to HTTP. > > We could also "extend" on JSON-RPC by being able to switch serializers giving > us the ability to support BSON and protobuff as long as the clients adhere to > the strong types in the schema. > Unlike XML-RPC that uses advanced XML features, JSON-RPC can really be any > serialized object. So technically, if de\serialization becomes an issue we > could put high performance serializers as configurable options for very large > scale deployments. > > JSON-RPC also supports extension methods that can be used to extend the > protocol. > > As I see it this solves all the issues that were preventing us from > committing to a protocoll. > * We don't want to be bound to a single transport. (Transport agnostic) > * We don't want to be bound to a single serializer (Solved with optional > extension that could be added when we need it) > * 2 way communication (if you use anything other then HTTP you have that) > * low latency (If you use anything other then HTTP you have that too) > * Removal of calls that are actually a group of calls (eg. > connectStorageServers vs connectStorageServer) - Even with HTTP, JSON-RPC > supports request lists which give the expected semantic. > * Simple set-up. Using ZMQ, HTTP or TCP Socket you can setup VDSM without a > broker. > * Don't have a lot of big classes for bindings. Because we bind int the > transport level the amount of methods per transport is minimal and constant. > * We provide the bindings. Bindings we'll be available and generated from the > schema. So there is no problem with the (everyone needs to write their own > bindings). > * Allow bridges. Someone can still write a lightweight REST bridge over the > bindings\socket. > > Is there something that this doesn't solve?
Thanks for the additional detail. How is this proposal different from what I have submitted to gerrit other than we now need to write an additional Java bindings generator? > > > > > > > > ----- 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 > > > > > > > > > > > > > > > -- > > Adam Litke <[email protected]> > > IBM Linux Technology Center > > > > > -- Adam Litke <[email protected]> IBM Linux Technology Center _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
