On 10/9/06, Jean-Marc Orliaguet <jmo@ita.chalmers.se> wrote:
That's basically what I wrote the other day (The Times... ) : as an application designer you want a *plugin architecture* with greasy fat components, not an architecture with hundreds of micro-components wired together like this: http://jacobswellchurch.org/tim/archives/wires-bottom.jpg that require that learn the internals.
Also, "plugin logic" is not the same as "micro-component logic":
- plugins are single units that only need a runtime platform to get working, while micro-components need to get assembled before they can be used, the border between the platform and the platform's components is very blurry.
- plugins have a public API that preserves backward compatibility, and hence preserves user's investments, while micro-components neither have a public or private API, they implement interfaces (interface != API)
- plugins can get loaded and unloaded at runtime, or updated, while micro-components are basically added once at server startup time and they never get changed at run-time.
- a plugin architecture can manage dependencies between plugins.
- plugins are useful to market an architecture, (cf. Photoshop gimp, Gimp plugins, VDR plugins (http://www.cadsoft.de/vdr/plugins.htm), Firefox plugins, skins, Azureus plugins, Eclipse plugins ...). It is easy to explain what a plugin does in terms of functionality, while it is difficult to explain what a micro-component does.
//- plugins encourage participation!!! (that's one of the reason of the success of Plone IMO: every one feel that they can create their own product, by looking at other existing products), while micro-components are difficult to grasp.
- plugins can be used by end-users, while micro-components are designed by developers for developers.
That's not at all what I said. ;) But you have valid points and I basically agree with your separations of micro-components and plugins. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/