E4/Pervasive Themes

At the E4/Summit, some pervasive themes that may affect all of E4 have been identified:

• E4/Architectural Foundations
• E4/Eclipse Application Model

This page is to collect ideas and start drafting architecture early in areas that would be hard to change after the fact. We'll also need to find out how to best communicate about these pervasive themes, and hopefully find leaders.

Reducing Bloat

• Apparently, reducing bloat requires unifying things that used to be done separately, which makes it a prime candidate for a Pervasive Theme.
• Where do we see bloat that could be avoided?
  • Too many Listeners

Too Many Listeners

• Can we agree on a common listener model? Some candidates are
  • Databinding Observables
  • EMF eObject (Drawback: Every Observable needs to extend eObjectImpl, no possibility for mix-in)
  • Other hand-written infrastructure?
  • Anything else?

Becoming More Asynchronous

• Being Asynchronous is not just a matter of adding callbacks. Here's some questions to solve:
  • How to debug a program that doesn't exhibit synchronous flow of operation? It needs to be easy to navigate from an API Call into the callback in order to set a breakpoint there.
  • How to perform Exception Handling? Callbacks will be executed in arbitrary Threads determined by the Framework. Clients may need to register exception handlers in order to react to exceptions in client code properly.
  • Logging and Tracing. With the logical flow of operation in a component split into multiple separate API Calls / Callbacks, it gets hard to trace overall program execution. An "overall" tracer that takes all requests into account might be needed in addition to trace filtering for individual components or individual requests only.
  • Threading. Should there be specifications what threads are used to call back into application code?
  • State Maintenance, Locking and Deadlock Avoiding. Are clients allowed to maintain state between an API call and its callback? If yes, then this introduces some kind of lock on the component, since the state must not be modified before the callback gets in. In other words, just becoming asynchronous is not a guarantee that locking and deadlocks are no issues. We could enforce a RESTful model without maintaining state, or re-invent scheduling rules in order to avoid the risk of data / state corruption or deadlock.
  • Boilerplate Code. Callbacks typically require code such as

theService.invoke(new ICallback() {
   public void done(ICallbackResult result) {
      moveOn(result);
   }
});

Such boilerplate code should be consistent across E4 in order to support tooling at some point (Or will we want some kind of precompiler until we have Java 7 closures)?

• The Device Debugging DSF Framework is the most elaborate framework for dealing with asynchronous requests and callbacks that I know. Looking at their Design Documents may be helpful.

Depencency Injection

• Any patterns on how to actually use it? And when to use it?
• Any initial code?

Application Model and Commands

• Will there be a new story for hooking up services, registering commands and reacting to them?