----- 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 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
