[ovirt-devel] Thoughts on modularization

Fri Nov 7 17:10:42 UTC 2014

Hi Mark, sorry for late response.

I've looked at GWTP -> UberFire migration presentation, looks interesting.

It will be best if we discuss everything next week, I'll schedule a meeting
on Monday (Nov 10) and also share it on devel-list for anyone interested to
participate.

@other, if you're interested in GWT, GWT-Platform, GIN, Errai, CDI, UberFire
or JavaScript in general, please join this session.

Some inline comments below.

Regards,
Vojtech

----- Original Message -----
> From: "Mark Proctor" <mdproctor at gmail.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, devel at ovirt.org
> Sent: Wednesday, November 5, 2014 5:06:24 PM
> Subject: Re: [ovirt-devel] Thoughts on modularization
> 
> Not sure if my previous email made it to the wider level at ovirt.org list. I
> just subscribed :) So I’ll repeat the info.
> 
> Here is a migration path, with detailed explanation on GWTP mappings:
> https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-dKQSgHPX6rU/edit#slide=id.p14
> <https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-dKQSgHPX6rU/edit#slide=id.p14>
> 
> Here presentation I gave yesterday, showing all the work we’ve done in BRMS
> and BPMS and doing.
> http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html
> <http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html>
> 
> It also shows a little around our Screens and Perspective plugins, or two
> units of extensions.  Both of which have polyglot bindings (GWTExported,
> will migrate to @JsType later). Implicitly Maven is our unit of modularity,
> with maven dependency tree to declare this - however this is not recognised
> in any internal registry. CDI just scans and picks up any @Screen,
> @Perspective etc. But could be added, to give physical representation of
> that unit of modality, with life cycle callbacks - we just haven’t had a
> need for this yet.

For us, I'd like to have modularity implemented in a way to avoid "the big
GWT app compilation" step. Doesn't matter if we ultimately go for "pure
modular" approach or "core that invokes modules" approach, the big goal
for us is to split frontend build into several projects.

Maven as unit of modularity is cool but only for compile-time-known projects.
I'd like to try a different approach, as you wrote - give them some physical
representation and load them at runtime.

> 
> Our plan over 2015 is to use JsType to create a contract for all the things a
> module needs. We will then compile modules separately against this, with
> iframe separation, so each Module is loaded as a separate GWT app. This does
> mean GWT core repetition, a pita, but that atleast gets us started and may
> be solvable by a custom GWT linker.

Actually, this iframe approach is what we took in oVirt UI plugins! :)

So I see that you're approaching modules from GWT perspective, sounds
interesting. However, there are already existing JS frameworks and tools
that solve modularization (but they come from JS perspective), like
RequireJS (AMD) or ES6's module spec. Assuming JS is here to stay as the
dominant web UI technology, I'd rather utilize existing ES6 modules than
implementing some GWT-specific module system on my own. But let's discuss
that in detail next week.

> 
> Longer term we’d like to work with GWT team. They now use the Closure
> compiler, this support symbol tables, and I expect how their incremental
> compiler works for their super dev mode. We want to achieve two things 1)
> stop recompilation of maven modules, when aggregated into sub projects. 2)
> declare apis that cannot be pruned 3) export a symbol table to allow later
> compilation of runtime extensions against those, without requiring a
> repetition of the GWT core (i.e. problem with our first attempt).

Very interesting stuff! :)

> 
> We will still continue with our polyglot bindings approach, such as with the
> AngularJS stuff we have done. But I do not see this as the ideal programming
> model - it hides much of what Errai brings, around event bus, and general
> java refactoring capabilities. However it is still useful for our customers,
> who want to write extensions, but do not want to touch or learn GWT.

If we take modular approach, nothing prevents us to implement "root"
module in UberFire/Errai and expose high-level API for sub-modules
to consume. Sure, GWT/Java brings advantages of Java statically typed
language and its development/build tools, I agree. The concept of event
bus is also good as it allows decoupling of application components.

For me, learning lessons from oVirt UI plugins, I'd rather avoid the
"have core app as runtime monolith and just expose some JS API for
small extensions customers can do" scenario. I'd rather treat both
core and 3rd party modules/extensions on the same level.

> 
> Mark
> 
>  
> > On 5 Nov 2014, at 15:32, Alon Bar-Lev <alonbl at redhat.com> wrote:
> > 
> > 
> > 
> > ----- Original Message -----
> >> From: "Vojtech Szocs" <vszocs at redhat.com>
> >> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >> Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> >> Sent: Wednesday, November 5, 2014 5:24:14 PM
> >> Subject: Re: [ovirt-devel] Thoughts on modularization
> >> 
> >> 
> >> 
> >> ----- Original Message -----
> >>> From: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> To: "Vojtech Szocs" <vszocs at redhat.com>
> >>> Cc: devel at ovirt.org, "Mark Proctor" <mdproctor at gmail.com>
> >>> Sent: Wednesday, November 5, 2014 4:12:06 PM
> >>> Subject: Re: [ovirt-devel] Thoughts on modularization
> >>> 
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Vojtech Szocs" <vszocs at redhat.com>
> >>>> To: devel at ovirt.org
> >>>> Cc: "Mark Proctor" <mdproctor at gmail.com>
> >>>> Sent: Wednesday, November 5, 2014 5:04:24 PM
> >>>> Subject: [ovirt-devel] Thoughts on modularization
> >>>> 
> >>>> Hi guys,
> >>>> 
> >>>> I've discussed this recently with Yair and Mark, I just wanted to share
> >>>> some more thoughts on this topic -- in particular, how modularization
> >>>> problem can be approached (regardless of implementation details).
> >>>> 
> >>>> I see two approaches here. The typical one is to define APIs for modules
> >>>> to consume. For example, oVirt Engine extension API has API for auth
> >>>> stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc.
> >>>> The advantage is strict consistency, disadvantage is burden of having
> >>>> to maintain the whole API. With this approach, you tell modules: "This
> >>>> is the API to work with system, defining how you can plug into it."
> >>>> 
> >>>> Now turn 180 degrees. The other approach, which is really interesting,
> >>>> is to let modules themselves export API. This naturally leads to module
> >>>> hierarchies. Ultimately, this leads to micro-kernel-style development,
> >>>> where all logic resides in modules. Now you might ask: "What if we want
> >>>> to employ some consistent work flow across multiple modules? For
> >>>> example,
> >>>> have some pluggable *auth* infra?" -- this can be done via some "higher"
> >>>> level module, that exports API and "lower" level modules consume that
> >>>> API.
> >>>> 
> >>>> If you have any ideas, please share!
> >>> 
> >>> Both solutions can be applied using existing extension api, an extension
> >>> can
> >>> locate other extension and interact with it the same way the core
> >>> interacts
> >>> with extensions.
> >> 
> >> But how does core interact with extensions? I assume via well-defined
> >> API, i.e. in accordance with first approach mentioned above.
> > 
> > presentation:
> > http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
> > <http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf>
> > 
> > package org.ovirt.engine.api.extensions;
> > 
> > /**
> > * Interface of an extension.
> > */
> > public interface Extension {
> > 
> >    /**
> >     * Invoke operation.
> >     * @param input input parameters.
> >     * @param output output parameters.
> >     *
> >     * <p>
> >     * Interaction is done via the parameters.
> >     * Exceptions are not allowed.
> >     * </p>
> >     * <p>
> >     * Basic mappings available at {@link Base}.
> >     * </p>
> >     *
> >     * @see Base
> >     */
> >    void invoke(ExtMap input, ExtMap output);
> > 
> > }
> > 
> >> With second approach mentioned above, core would not interact with
> >> extensions at all (or in a very limited way), instead - extensions
> >> would interact with each other. In other words, extension would not
> >> need to implement core-specific API (there would be none), instead
> >> it would inject its dependencies (other modules/extensions) and
> >> consume their APIs. This is the difference I wanted to point out :)
> > 
> > The extension interface is primitive to enable exactly that, provided java
> > people will open their minds :)
> > 
> > Regards,
> > Alon
> 
> 