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

Vojtech Szocs vszocs at redhat.com
Thu Nov 28 19:39:23 UTC 2013 


----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
> Sent: Sunday, November 24, 2013 9:38:45 AM
> Subject: Re: Using REST API in web UI - review call summary
> 
> On 11/22/2013 12:08 AM, Vojtech Szocs wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Vojtech Szocs" <vszocs at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen"
> >> <ecohen at redhat.com>, "Michael Pasternak"
> >> <mpastern at 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" <iheim at redhat.com>
> >>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>
> >>>> Cc: "Einav Cohen" <ecohen at 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.

Yes, Java SDK will be our reference when developing JavaScript binding for REST API [1]: "It would contain everything currently offered by existing Java SDK".

[1] http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI#REST_API_JavaScript_Binding

> 
> > 
> >>
> >>>
> >>>>
> >>>> 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
>

More information about the Engine-devel mailing list