On 11/28/2013 09:22 PM, Vojtech Szocs wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" <mpast...@redhat.com> >> To: "Vojtech Szocs" <vsz...@redhat.com> >> Cc: "engine-devel" <engine-devel@ovirt.org> >> Sent: Sunday, November 24, 2013 9:07:01 AM >> Subject: Re: [Engine-devel] Using REST API in web UI - review call summary >> >> >> >> Hi Vojtech, >> >> 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 >>> 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 ... > > Of course, but by saying "coupling ourselves to Java SDK" I meant SDK > perspective, not client perspective:
of course, but you told something different, that you want js-sdk to be aware of the client, and this is actually why you taking this path. > > - 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 (supported) customizations > - 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 that's how things working in software, you always depending on the certain version of the component you're working against, as it expose set of features you need, i don't think that having control over framework features, justifying rewriting the framework ... (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i just can't see the business case for not reusing existent infrastructure cause it works for all your needs and eventually both worlds would benefiting from it UI and java-sdk users cause you where extending it with additional capabilities they may also need) > > For the sake of simplicity, I guess it's best to start with SDK that has no > dependencies whatsoever. so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it, this way you'll have control over it (and it's features) as well ;-) > After all, there's no common dependency (aside from running Engine to provide > XSD & RSDL) between Java & Python SDK too, if I understand correctly. > > 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 requirements. it would be true, if your requirements would make existing infrastructure inappropriate. > >> >>> >>> 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"? > > 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" if you need additional functionality in java-sdk, you could do the following: 1. submit a patch to java-sdk 2. build new java-sdk locally and use it along with new feature you've added 3. make UI depending on next version of java-sdk (which includes your new feature) we (and all other SW projects) doing that day by day in engine,api,etc. (as i mentioned this would also benefit java-sdk users with additional features they might find useful as well) > > (by "people" I meant "JavaScript SDK developers") > > 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. i disagree on this one, you have all control you need over java-sdk at any time as it one of indoor projects. > And of course, this assumes that existing code (Java SDK) provides everything > we need, which might or might not be the case. > > So I just vote for simplicity, generate JavaScript SDK the way like other > SDKs (Java/Python) - not trying to reuse anything, just grab XSD & RSDL and > generate sources. > >> 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. > > +1 > > 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 >>> 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, > > 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: Vojtech, you've got all wrong, i told that you *do need* callbacks, but implementing them only sounds easy, while actually it will be a quite complicated task. > > - 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 callback > >> >> 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. > > First of all, I don't understand how callback mechanism can be CPU consuming, > can you please provide some explanation or use case? of course, you'll have to do per call-back call: 1. request/response to the server 2. decompression of data from gzip 3. object mapping (in 99% of cases) note you'll have a lot of callback consumers that monitoring resource state, waiting for new events. > > Does Java SDK provide ability to poll Engine in order to get recent updates, > and if yes, why? i was kinda hoping that you'll add it, but you've chosen to write your own sdk ;-) > > 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 this goal. sdk cannot be stateful by definition simply because server is stateless, (also pooling != keeping state, being stateful means that you save data for request on server side) > >> >>> >>> [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 >>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> -- Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
