Re: [ovirt-devel] Thoughts on modularization

From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; Cc: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt;, "Mark Proctor" <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org Sent: Friday, November 7, 2014 5:17:56 PM Subject: Re: [ovirt-devel] Thoughts on modularization Hi, I can summarized that you want again to go into the "Java way" and not the "Simple/primitive way". I think it is a mistake and will not have any benefit, "API" can be a wrapper over primitive interaction. We were there at past discussions, and as there is no leader of project we can discuss this to death, and I am not intend to do this yet another time (we have done this at branding, we have done this for aaa, partially for ui plugins [there we should kill gwt], and ...). I will make this short... 1. the current extension api is sufficient to construct a very complex implementation using very simple and primitive interface. 2. the current extension api enable implementing extensions using non java technologies, such as javascript/jpython. 3. the current extension api enable to not have any difference if core or extension interacts with extensions. 4. the current extension api enable forward and backward compatibility in simple methodology,. 5. a wrapper over the extension api can provide whatever high level api that is preferred by developer as an optional utility. we can always over engineer solution or have java specific solutions, I always vote for simplicity.

Alon ----- Original Message ----- > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; > Cc: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "Mark Proctor" > <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org > Sent: Friday, November 7, 2014 4:53:49 PM > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > ----- Original Message ----- > > From: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > Cc: "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Mark Proctor" > > <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org > > Sent: Wednesday, November 5, 2014 9:40:05 PM > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt;, devel(a)ovirt.org > > > Sent: Wednesday, November 5, 2014 6:16:15 PM > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > Sent: Wednesday, November 5, 2014 6:07:50 PM > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > > Sent: Wednesday, November 5, 2014 4:32:31 PM > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > > > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > > > Sent: Wednesday, November 5, 2014 5:24:14 PM > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > > > > > > To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > > > > Cc: devel(a)ovirt.org, "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > > > > Sent: Wednesday, November 5, 2014 4:12:06 PM > > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Vojtech Szocs" <vszocs(a)redhat.com&gt; > > > > > > > > To: devel(a)ovirt.org > > > > > > > > Cc: "Mark Proctor" <mdproctor(a)gmail.com&gt; > > > > > > > > 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? > > > > > > correct, and nothing prevents extension to invoke other extensions. > > > > > > > > > > > > > > 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 > > > > } > > > > > > you again using java magic for something that can go to declaration... > > > > Vojtech, I have to agree with Alon here, > > as much as I enjoyed in the past seeing hibernate move to annotations , I > > think in our case a configuration file is better. > > I'm not against config files, annotations are static metadata too anyway. > > > > > > > > > > > > > > * API for fetching modules, i.e. getModuleByName('xxx') > > > > > > there is no need as within the extension context you have access to > > > this > > > information, all you need is iterate a list, see Base.java. > > > > > > > API for exporting module API, i.e. exportApiObject(foo) > > > > > > not sure why it is needed... once extension is loaded it is available. > > > > > > > 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.) > > > > > > not sure I understand what is the functionality difference between this > > > and > > > the primitive approach we already have... > > > > > > 1. every configuration at /etc/ovirt-engine/extensions.d and > > > /usr/share/ovirt-engine/extensions.d are loaded during engine startup. > > > > > > 2. each extension has two phases load and init, during init an > > > extension > > > can > > > locate other extensions by name via its context. it is true that > > > probably > > > missing functionality is to support ordering of the init and load, we > > > left > > > it into future as there was no actual need for this. > > > > > > 3. each extension can interact with other extension. > > > > > > 4. there must be core model to trigger the entire thing, core cannot be > > > just > > > a loader. > > > > Alon, can you elaborate here on number 4? > > In an ideal world, wouldn't you want to have the "engine core" be a small > > as > > something that goes over the extensions and loads them? and maybe let > > each > > extension expose somehow its relevant part of rest-api (besides of using > > ext-api to interact between extension and of course each extension should > > have the relevant logic implementerd within) > > > > > > > > Alon > > > _______________________________________________ > > > Devel mailing list > > > Devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > >