Re: [Engine-devel] Using REST API in web UI - review call summary

----- Original Message ----- Thank you :) 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 (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 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 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'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" (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. 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. +1 I agree with you on this. 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. 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 callback 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, why? 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.