[ovirt-devel] Thoughts on modularization
Yair Zaslavsky
yzaslavs at redhat.com
Sat Nov 8 09:46:53 UTC 2014
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>, "Mark Proctor" <mdproctor at gmail.com>, devel at 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.
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" <vszocs at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "Alon Bar-Lev" <alonbl at redhat.com>, "Mark Proctor"
> > <mdproctor at gmail.com>, devel at ovirt.org
> > Sent: Friday, November 7, 2014 4:53:49 PM
> > Subject: Re: [ovirt-devel] Thoughts on modularization
> >
> >
> >
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Mark Proctor"
> > > <mdproctor at gmail.com>, devel at 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 at redhat.com>
> > > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > > Cc: "Mark Proctor" <mdproctor at gmail.com>, devel at ovirt.org
> > > > Sent: Wednesday, November 5, 2014 6:16:15 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 6:07:50 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: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?
> > > >
> > > > 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 at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > >
> > >
> >
>
More information about the Devel
mailing list