----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Vojtech Szocs" <[email protected]> > Cc: "Yair Zaslavsky" <[email protected]>, "Mark Proctor" > <[email protected]>, [email protected] > 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.
Hmm, I think that going the "Java way" will be a bit "sad", especially since objects in JS are maps. I understand that GWT stuff gets compiled from Java, and since Java is more strongly typed and we have Java classes to work with, Vojtech is looking probably to a solution which is more "the java way". Having said that, I still see no reason why we can't use ExtAPI in GWT, yes, maybe we will need to do some "porting" so it matches the GWT java limitations, and yeah - we cannot use JBoss modules there, we need something else (and we can't use JS either, as JS is the compilation result) - but still, if possible I would consider to try use EXTAPI in GWT as well. Yair > > Alon > > ----- Original Message ----- > > From: "Vojtech Szocs" <[email protected]> > > To: "Yair Zaslavsky" <[email protected]> > > Cc: "Alon Bar-Lev" <[email protected]>, "Mark Proctor" > > <[email protected]>, [email protected] > > Sent: Friday, November 7, 2014 4:53:49 PM > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" <[email protected]> > > > To: "Alon Bar-Lev" <[email protected]> > > > Cc: "Vojtech Szocs" <[email protected]>, "Mark Proctor" > > > <[email protected]>, [email protected] > > > Sent: Wednesday, November 5, 2014 9:40:05 PM > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" <[email protected]> > > > > To: "Vojtech Szocs" <[email protected]> > > > > Cc: "Mark Proctor" <[email protected]>, [email protected] > > > > Sent: Wednesday, November 5, 2014 6:16:15 PM > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Vojtech Szocs" <[email protected]> > > > > > To: "Alon Bar-Lev" <[email protected]> > > > > > Cc: [email protected], "Mark Proctor" <[email protected]> > > > > > Sent: Wednesday, November 5, 2014 6:07:50 PM > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Alon Bar-Lev" <[email protected]> > > > > > > To: "Vojtech Szocs" <[email protected]> > > > > > > Cc: [email protected], "Mark Proctor" <[email protected]> > > > > > > Sent: Wednesday, November 5, 2014 4:32:31 PM > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Vojtech Szocs" <[email protected]> > > > > > > > To: "Alon Bar-Lev" <[email protected]> > > > > > > > Cc: [email protected], "Mark Proctor" <[email protected]> > > > > > > > Sent: Wednesday, November 5, 2014 5:24:14 PM > > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Alon Bar-Lev" <[email protected]> > > > > > > > > To: "Vojtech Szocs" <[email protected]> > > > > > > > > Cc: [email protected], "Mark Proctor" <[email protected]> > > > > > > > > Sent: Wednesday, November 5, 2014 4:12:06 PM > > > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Vojtech Szocs" <[email protected]> > > > > > > > > > To: [email protected] > > > > > > > > > Cc: "Mark Proctor" <[email protected]> > > > > > > > > > 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 > > > > [email protected] > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > > > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
