From ACM Queue about frameworks and plug-ins...
This article identifies some of the concepts around the foundation of pure plug-in architectures and how they affect various stakeholders when taking a plug-in approach. The intention is to discuss the general issues involved, but the article also presents some lessons learned from Eclipse (www.eclipse.org) to better illustrate some of the concepts.The main problem with a framework like Eclipse is that so many unnecessary dependencies are forced on plug-in developers. You have to buy the full Eclipse approach to get even half the benefits.
What lessons have we learned in the last 15 years of building frameworks like this? Are we having trouble understanding what is important, what has been learned already in the software industry?
Why build a framework like Eclipse in the 21st century when you could build a framework like FIELD which was built in the 1980s? Certainly the full benefits of Eclipse could be built *using* an approach like FIELD's. Plug-ins that did not or could not support the full benefits of Eclipse would then have fall-back positions. New approaches could evolve that stretch beyond the imaginary boundaries of the current Eclipse framework.
What is it about FIELD? Well FIELD is based on integrated components loosely coupled via asynchronous message passing.
That may ring a bell for 21st century programmers.