Re: [ovirt-devel] Thoughts on modularization

5 Nov 2014

      ----- Original Message -----
...
From: "Vojtech Szocs" <vszocs@redhat.com>
To: "Alon Bar-Lev" <alonbl@redhat.com>
Cc: devel@ovirt.org, "Mark Proctor" <mdproctor@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@redhat.com>
To: "Vojtech Szocs" <vszocs@redhat.com>
Cc: devel@ovirt.org, "Mark Proctor" <mdproctor@gmail.com>
Sent: Wednesday, November 5, 2014 4:12:06 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
----- Original Message -----
...
From: "Vojtech Szocs" <vszocs@redhat.com>
To: devel@ovirt.org
Cc: "Mark Proctor" <mdproctor@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

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