Re: [Engine-devel] Using REST API in web UI - review call summary

----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Einav Cohen" <ecohen(a)redhat.com&gt;, "Michael Pasternak" > <mpastern(a)redhat.com&gt; > Sent: Thursday, November 21, 2013 11:00:25 PM > Subject: Re: Using REST API in web UI - review call summary > > On 11/21/2013 11:56 PM, Vojtech Szocs wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" <iheim(a)redhat.com&gt; >>> To: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "engine-devel" >>> <engine-devel(a)ovirt.org&gt; >>> Cc: "Einav Cohen" <ecohen(a)redhat.com&gt; >>> Sent: Thursday, November 21, 2013 10:25:04 PM >>> Subject: Re: Using REST API in web UI - review call summary >>> >>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote: >>>> Hi guys, >>>> >>>> this is a summary of yesterday's review call, I'll try to highlight >>>> important Q/A and things we agreed on. Feel free to add anything in case >>>> I've missed something. >>>> >>>> -- >>>> >>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT >>>> apps? (asked by Michael & Gilad) >>>> >>>> A: This might be a viable option to consider if we wanted to skip >>>> JavaScript-based SDK altogether and target Java/GWT code directly; we >>>> could simply take Java SDK and customize its abstractions where >>>> necessary, >>>> i.e. using HTTP transport layer implementation that works with GWT. In >>>> any >>>> case, this would mean coupling ourselves to Java SDK (which has its own >>>> release cycle) and I think this would complicate things for us. >>>> >>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK >>>> as >>>> the lowest common denominator for *any* web application that wants to >>>> work >>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. >>>> Java/GWT code that just overlays objects and functions provided by >>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see >>>> JavaScript SDK's code generation process to be independent of any other >>>> SDK (people responsible for maintaining JavaScript SDK should have full >>>> control over generated code). >>>> >>>> -- >>>> >>>> Q: What about functionality currently used by oVirt UI but not supported >>>> by >>>> REST API? (asked by Einav) >>>> [For example, fetching VM entity over GWT RPC also returns related >>>> data >>>> such as Cluster name.] >>>> >>>> A: Based on discussion I've had with other colleagues after yesterday's >>>> review call, I don't think that separate support-like backend layer is a >>>> good idea. Instead, this is the kind of functionality that could be >>>> placed >>>> in oVirt.js library. Logical operations like "get VMs and related data" >>>> would be exposed through oVirt.js (callback-based) API and ultimately >>>> realized as multiple physical requests to REST API via JavaScript >>>> Binding. >>>> >>>> oVirt.js client would be completely oblivious to the fact that multiple >>>> physical requests are dispatched. In fact, since HTTP communication is >>>> asynchronous in nature, oVirt.js client wouldn't even notice any >>>> difference in terms of API consumption. This assumes JavaScript SDK would >>>> use callback-based (non-blocking) API instead of blocking one - after >>>> all, >>>> blocking API on top of non-blocking implementation sounds pretty much >>>> like >>>> leaky abstraction [1]. >>>> >>>> For example: >>>> >>>> sdk.getVmsWithExtraData( >>>> callbackToGetExtraDataForGivenVm, // might cause extra physical >>>> requests to REST API >>>> callbackFiredWhenAllDataIsReady // update client only when >>>> all >>>> data is ready >>>> ) >>> >>> would this also resolve RunMultipleActions? >> >> Yes, I think so. There could be API to pass multiple "actions" and get >> notified when they complete. >> >>> sounds like no reason to have RunMultipleQueries, although i'm still >>> sure a single call to engine for multiple keys would be much more >>> efficient than multiple async calls? >>> (I understand we may not be able to model this). >> >> Efficiency-wise, yes, single call to get all data seems optimal. API-wise, >> I don't think it really matters from oVirt.js client perspective. >> >> We can proceed with simple (possibly inefficient) solution and improve as >> needed. We're making baby steps now.. >> >>> >>>> >>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction >>>> >>>> -- >>>> >>>> Last but not least, where to maintain JavaScript SDK projects: low-level >>>> JavaScript Binding + high-level oVirt.js library. >>>> >>>> I agree that conceptually both above mentioned projects should go into >>>> dedicated "ovirt-engine-sdk-js" git repository and have their own >>>> build/release process. However, for now, we're just making baby steps so >>>> let's keep things simple and prototype these projects as part of >>>> "ovirt-engine" git repository. >>>> >>>> ... we can complicate things anytime, but we should know that any complex >>>> system that works has inevitably evolved from simple system that works >>>> ... >>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law) >>> >>> I think the entities should just be generated from the xsd. >> >> +1 >> >> The JavaScript Binding (aka low-level SDK) module should follow same >> concepts as existing Java SDK - generated entities decorated with >> operations to form fluent API. >> >> Everything Java SDK currently offers should be available in JavaScript >> Binding. oVirt.js is our opportunity to build on top of that. >> >>> for the rsdl, makes sense to start with clean code to see what works >>> best, then see about generating it (but you should adhere the rsdl as >>> guidlines i guess). >> >> +1 >> >> The initial prototype should be written by hand, things will get generated >> as soon as we have better idea how the end result should look like. > > i can understand that for the methods and maybe for populating the > entities for the first few. > the entities themselves, no point in hand coding - just generated them > from the api.xsd. > and once you decide how you want to fill them, not worth hand coding > this - either json gives this out of the box, or should be generated as > well. OK, now I get you :) sure, entities aren't too interesting by themselves, but populating (decorating) them is something that requires more thought.

> >> >>> >>> lets try to plan for lightweight entities while at it - the API has a >>> mechanism for different level of details - maybe we need a custom level >>> where the client specifies which fields they want back or something like >>> that. >> >> Good idea! We should definitely think about the granularity of entities. >> >> I didn't know REST API supports different level of detail per entity, is >> there some documentation for this feature? >> >> Since JavaScript is dynamic, one possible solution would be to let client >> define the entity structure (i.e. what data client needs) on the fly, >> during runtime :) > > michael? > >> >>> >>> Good luck, >>> Itamar >>> > >