On 11/21/2013 11:18 PM, Vojtech Szocs wrote:
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)
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.
common denominator for *any* web application that wants to work with REST API. oVirt
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
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
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
all, blocking API on top of non-blocking implementation sounds pretty much like leaky
callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST
callbackFiredWhenAllDataIsReady // update client only when all data is ready
would this also resolve RunMultipleActions?
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).
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
I think the entities should just be generated from the xsd.
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).
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