[ovirt-devel] Thoughts on modularization

[Vojtech Szocs]

----- 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.

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 :)

> 
> Alon
>