On 11/22/2013 12:08 AM, Vojtech Szocs wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" <ih...@redhat.com> >> To: "Vojtech Szocs" <vsz...@redhat.com> >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" >> <eco...@redhat.com>, "Michael Pasternak" >> <mpast...@redhat.com> >> 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" <ih...@redhat.com> >>>> To: "Vojtech Szocs" <vsz...@redhat.com>, "engine-devel" >>>> <engine-devel@ovirt.org> >>>> Cc: "Einav Cohen" <eco...@redhat.com> >>>> 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.
you have Java-SDK that does this already, so it should be relativity easy to take it from there. > >> >>> >>>> >>>> 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 >>>> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
