[ovirt-devel] Thoughts on modularization

[Vojtech Szocs]

----- 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:32:31 PM
> Subject: Re: [ovirt-devel] Thoughts on modularization
> 
> 
> 
> ----- 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

Thanks for sharing!

> 
> 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);
> 
> }

OK, so it was my lack of knowledge of AAA implementation :)

Since Extension interface is invoke-based, I assume that Engine
core (backend) invokes extensions on specific occasions, right?

> 
> > 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 :)

Simple interface means great flexibility, now I understand the
rationale behind typed maps in extension API.

What I had in mind was something like this (maybe crazy):

* imagine for a moment that the backend is fully modular
  (logic lives in modules, no logic outside modules)

* @DependsOn("SomeOtherModule") // modules can form hierarchies
  public class MyModule implements Module {
    public void loaded() {} // executed just once per module
  }

* API for fetching modules, i.e. getModuleByName('xxx')
  API for exporting module API, i.e. exportApiObject(foo)

This way, you'd have one "core" module, providing most general
functionality/abstractions. Then you'd have more specific modules,
plugged into "core" module's API etc. In other words, hierarchy of
modules. This is essentially modularization taken to extreme :)

(BTW, above is just an idea.)

> 
> Regards,
> Alon
>