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

[Vojtech Szocs]

Hi Sven, please find my comments inline.


----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Sven Kieske" <S.Kieske at mittwald.de>, engine-devel at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>