Re: [ovirt-devel] Thoughts on modularization

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.

Alon