----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, November 24, 2013 9:07:01 AM
Subject: Re: [Engine-devel] Using REST API in web UI - review call summary
First of all it was a good "presentation" of requirements + suggested
solutions - well done!,
Thank you :)
few comments/questions inline.
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
> 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.
not sure i buy this one :), this is the purpose of any sdk, including the
one you about to write, people that will use it, will be "coupling" to it ...
Of course, but by saying "coupling ourselves to Java SDK" I meant SDK
perspective, not client perspective:
- someone else (you) maintains Java SDK and therefore controls generated sources (JAR or
RPM isn't relevant here)
- another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some
- the only way I can impose changes in my SDK is through supported customizations as you
control original (Java SDK) sources,
i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to
your SDK's build/release cycle
For the sake of simplicity, I guess it's best to start with SDK that has no
dependencies whatsoever. After all, there's no common dependency (aside from running
Engine to provide XSD & RSDL) between Java & Python SDK too, if I understand
In other words, building on top of something existing (just because we can do that)
isn't always appropriate/flexible/efficient, it always depends on given context and
> the lowest
> common denominator for *any* web application that wants to work with REST
> API. oVirt GWT-based
> objects and functions
> generation process to be independent of any other SDK (people responsible
> should have full control over generated code).
what do you mean by "people should have full control over generated code"?
It's related to "coupling from SDK perspective" I mentioned above:
"the only way I can impose changes in my SDK is through supported customizations as
you control original (Java SDK) sources"
Full control means ability to change generated sources in whatever way desired, but
assuming the idea of reusing/customizing existing SDK code, aspect of full control is lost
in favor of reusing existing code. And of course, this assumes that existing code (Java
SDK) provides everything we need, which might or might not be the case.
(Java/Python) - not trying to reuse anything, just grab XSD & RSDL and generate
the purpose of
code generation is to ease maintenance, i.e you/maintainer should not write
once it available in api, just run CodeGen and you'll get it for free, but
this is zero control
I agree with you on this.
> 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
> 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
> (non-blocking) API instead of blocking one - after all,
> blocking API on top of non-blocking implementation sounds pretty much like
> leaky abstraction .
> For example:
> callbackToGetExtraDataForGivenVm, // might cause extra physical
> requests to REST API
> callbackFiredWhenAllDataIsReady // update client only when all
> data is ready
actually this the main bottleneck in moving UI to work on top of REST, and
most interesting/complex part of this project,
Agreed, it's because UI "got used to" using internal backend interface
concepts (actions, queries etc.) in the first place.. So we'll have to emulate what we
used to use to prevent regressions, maybe improve/refactor in future.
you should think of very wise polling mechanism cause callbacks is a nice
thing on paper, but behind the scene it all about polling:
- the entity/s till action got accomplished
- add to this updating different grids
- running multiple actions
- showing events
- and obviously much more
IMHO polling is just a workaround and indicates lack of proper notification solution.
Apparently, oVirt web UI isn't some CLI program for which HTTP request/response style
is sufficient. oVirt web UI is dynamic, interactive web application that displays/updates
data in real time. This is, in my opinion, quite a big difference.
I don't think callbacks are just a nice thing on paper. Callbacks are needed because
the underlying communcation is async in nature:
- caller invokes API function and provides callback to execute when operation completes
-> API is non-blocking
- polling attempts to detect change (i.e. operation completed) and notify the caller, so
it's also some sort of callback -> this is more complicated compared to simple
and don't forget that every polled entity should be marshalled from xml to
entity so at the end, "callbacks" mechanism will be extremely CPU consuming.
First of all, I don't understand how callback mechanism can be CPU consuming, can you
please provide some explanation or use case?
Does Java SDK provide ability to poll Engine in order to get recent updates, and if yes,
Finally, polling makes things stateful, whereas SDK code should be stateless instead. If
client wants to get recent updates, it should just use (stateless) SDK code to achieve
>  http://en.wikipedia.org/wiki/Leaky_abstraction
> 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
> Engine-devel mailing list
RedHat, ENG-Virtualization R&D