11:07 a.m.
Hi Vojtech,
First of all it was a good "presentation" of requirements + suggested solutions
- well done!,
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 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.
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 ...
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).
what do you mean by "people should have full control over generated code"? the
purpose of
code generation is to ease maintenance, i.e you/maintainer should not write the feature
once it available in api, just run CodeGen and you'll get it for free, but this is
zero control
over 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
)
actually this the main bottleneck in moving UI to work on top of REST, and
most interesting/complex part of this project,
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
and don't forget that every polled entity should be marshalled from xml to the
javascript
entity so at the end, "callbacks" mechanism will be extremely CPU consuming.
[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)
Regards,
Vojtech
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D