[Engine-devel] webadmin (vs) rest-api & transition plan

Hi devs, I want to talk about the current development style and the (somewhat) planned transition from webadmin today to a webadmin which uses REST for communication. I honestly don't see how this goal can be achieved, given the current development pattern, but I may be wrong. e.g. this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1061131 it asks for a feature being available in GUI/webadmin. I'm pretty sure this gets implemented and adds another feature to the list which is not implemented via REST, thus leading to an even higher gap between REST and webadmin. Following this pattern will make the goal of using REST everywhere not easier to achieve. If you really want to build everything upon REST, or at least, transition everything to REST, there should be a policy that new features should be developed for REST access first. I don't know if such a policy is already in place and I know it will take some time for the transition, but what I observe leads me to the conclusion that the gap gets greater. What do you think? Are there any plans inside RH which I don't know regarding this transition? Maybe something you can share with your REST-Users? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

On 02/06/2014 09:15 AM, Sven Kieske wrote:
Hi devs,
I want to talk about the current development style and the (somewhat) planned transition from webadmin today to a webadmin which uses REST for communication.
I honestly don't see how this goal can be achieved, given the current development pattern, but I may be wrong.
e.g. this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1061131
it asks for a feature being available in GUI/webadmin.
I'm pretty sure this gets implemented and adds another feature to the list which is not implemented via REST, thus leading to an even higher gap between REST and webadmin.
Following this pattern will make the goal of using REST everywhere not easier to achieve.
If you really want to build everything upon REST, or at least, transition everything to REST, there should be a policy that new features should be developed for REST access first.
I don't know if such a policy is already in place and I know it will take some time for the transition, but what I observe leads me to the conclusion that the gap gets greater.
What do you think?
Are there any plans inside RH which I don't know regarding this transition? Maybe something you can share with your REST-Users?
1. most feature do get developed with both api and ui. that's the default "policy" today. when this doesn't happen its either due to time constraints (which will not be an option with the move of the gui), or when there is uncertainty about the modeling, due to concern feedback on the feature will require to change it. 2. moving the gui to be on top of the api will force everything to have the api. 3. once this happen, parts of the api may be defined as 'unstable', if there is a feeling they may still change if there is a feeling the feature may need to evolve a bit based on feedback.

Hi Sven, please find my comments inline. ----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Sven Kieske" <S.Kieske@mittwald.de>, engine-devel@ovirt.org Sent: Thursday, February 6, 2014 11:00:32 AM Subject: Re: [Engine-devel] webadmin (vs) rest-api & transition plan
On 02/06/2014 09:15 AM, Sven Kieske wrote:
Hi devs,
I want to talk about the current development style and the (somewhat) planned transition from webadmin today to a webadmin which uses REST for communication.
We have design proposal for using REST API in (all of) our GUI: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI Discussions as well as "design proposal review call" [1] took place mostly in November last year. [1] https://www.mail-archive.com/engine-devel@ovirt.org/msg05383.html I'm planning to start working on this in near future.
I honestly don't see how this goal can be achieved, given the current development pattern, but I may be wrong.
e.g. this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1061131
it asks for a feature being available in GUI/webadmin.
I'm pretty sure this gets implemented and adds another feature to the list which is not implemented via REST, thus leading to an even higher gap between REST and webadmin.
Following this pattern will make the goal of using REST everywhere not easier to achieve.
If you really want to build everything upon REST, or at least, transition everything to REST, there should be a policy that new features should be developed for REST access first.
I agree, new functionality should (always) be added to REST API in the first place. However, take into account existing GUI codebase that currently uses GWT RPC mechanism. The plan might look like this: 1, develop REST API JavaScript binding [*] 2, prototype REST API usage in GUI code & UI plugins 3, develop oVirt.js library [*] 4, step-by-step, migrate GUI code to use oVirt.js [*] Java/GWT overlay for easy integration in GWT-based GUI will be generated out of corresponding JavaScript code For details on JavaScript binding and oVirt.js, please refer to design proposal wiki mentioned above.
I don't know if such a policy is already in place and I know it will take some time for the transition, but what I observe leads me to the conclusion that the gap gets greater.
What do you think?
Are there any plans inside RH which I don't know regarding this transition? Maybe something you can share with your REST-Users?
1. most feature do get developed with both api and ui. that's the default "policy" today. when this doesn't happen its either due to time constraints (which will not be an option with the move of the gui), or when there is uncertainty about the modeling, due to concern feedback on the feature will require to change it.
Once we have stable JavaScript SDK & GUI code (infra) ready for its consumption, all new features can be done in REST API and exposed to GUI via JavaScript SDK. Existing code needs to be refactored to abandon action/query concept and utilize JavaScript SDK instead.
2. moving the gui to be on top of the api will force everything to have the api. 3. once this happen, parts of the api may be defined as 'unstable', if there is a feeling they may still change if there is a feeling the feature may need to evolve a bit based on feedback.
We can consider REST API versioning (or similar concept) for this purpose, with "unstable" on top of "stable" in terms of implementation flow.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (3)
-
Itamar Heim
-
Sven Kieske
-
Vojtech Szocs