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
)
[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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
