Difference between revisions of "E4/Architectural Foundations"

Revision as of 13:16, 22 May 2008

From discussions at the e4/Summit and Architecture Council/Minutes May 15 2008#Executive Summary of the Discussion:

Singletons

• General consensus that singletons are bad and should be avoided.
• Oleg: a related question from observing code patterns developers use. We see 100s of singletons per 1 OSGi service. This is a natural state as singletons are so much easier to use. Do we need to fight this or should we adapt to the use of singletons? The singleton and dependency injection should be complimentary, not mutually exclusive. Yes, singletons are easy to use, but only until you realize that you need two of the same kind (and only if it's for testing purposes). Then going through the code and getting rid of assumptions like that there is only ever one Workspace is really hard. -- BorisB

Dependency Injection

• Consensus that dependency injection is good. Has a fundamental impact on the entire Platform in terms of programming model, ease of testing etc.
• Clients should be able to "just write POJOs" and list the services they need.
• Concerns about discoverability of services - cannot use code completion to find out what is available.
• Like to avoid containerisms - having code that makes assumptions about which context it is being used in.
• Can be used at different levels of granularity. Do you inject small individual services, or larger objects that provide more functionality?
• Closely related to Application Model -- If components (view, editor) shouldn't know about the context in which they appear, dependency injection is a technique for this. Instead of PlatformUI.getWorkbench.getHelpSystem(), have the HelpSystem constructor injected.
• Need to take a look at the existing dependency injection mechanisms: DS, Springs, extension registry to see what works and what does not.
• Observation that we don't see dependency injection frameworks for dynamic languages (JavaScript, Smalltalk, Ruby). Why is that?

API Consistency

• One consistent API to access/modify/listen to tree-shaped structures for things like preference store, extension registry, IMemento, etc.
• How can we describe API in a language-independent way?

Too Many Listeners, Event Storms

• There are three distinct problems:
  • too many different listener classes -- need to unify on generic Listener architecture
  • too many listener instances -- a general Command Bus / Event Bus may help. Related to Application Model / Commands / Macro Recording.
  • event storms -- really big cause-and-effect trees, leading to duplicate work in listeners that get hit more than once, or doing too much work by being eager instead of lazy.
  • Champions to sit and merge concepts from (EMF, DataBinding, Others)
  • Also see this older proposal for a common notification mechanism

Distribution (e.g. Client/Server)

Concurrency

Security

• Different levels of security:
  • Making sure that only signed code is deployed.
  • Making sure that only signed code is loaded.
  • Ensuring that code cannot do certain things like accessing the local disk etc.
  • Having application-level concepts like user/session/roles.
• Maybe it is good enough to cover the first two levels?

Becoming More Asynchronous

• From Architecture Council/Minutes May 15 2008#Becoming More Asynchronous
  • Need a consistent overall picture; get above the level where we deal with these things one by one
  • Jobs and Scheduling Rules have some problems; DataBinding Realms and Runnables are good; We have too many Runnables; Futures could be a solution
  • Too many different ways of doing things, a more consistent Application Model would help getting more asynchronous
  • Consistent (machine-usable?) Documentation of Concurrency Properties
  • Recommend usage, e.g. Avoid Modal Dialogs; Verboten: Spinning the event loop
  • However, note lessons learned from the extension registry: data passed in asynchronous notifications should represent "an island"; it should be isolated from the current data with no way to navigate from the notification's data into the current data
• Pawel Piech (pawel.piech@windriver.com): If E4 is going to explore a new concurrency model for Eclipse, I think it ought to look at the DSF framework in the DSDP/DD project (the main concurrency package in DSF is here). It is based on the Executor, with the same extension as Realm to allow the caller to check whether he's in the executor thread. However the main communication method between realms is a callback object: RequestMonitor, the use of Future is avoided when possible because it easily leads to deadlocks. We've learned quite a bit over the last couple of years of using this framework and we'd be happy to share our lessons learned with E4, although I'm afraid I'm not able to attend the E4 summit.
• Scott Lewis (slewis at composent.com): It would be useful to have multiple primitives for interprocess and inter-thread communication...e.g. proxy (blocking/call return), async w/callback, futures/asychresult. ECF has a remote services API that provides these primitives for services, with an explicit approach for handling partial failure...via methods exposed by IRemoteService interface. Also, replicated models should also be considered, and the ECF shared object API can/could be used to support such approaches.

Java 5 Usage

• Should the Platform start using Generics and other Java 5 Concepts?
• Could there be tooling to allow writing code with Generics and other Java 5 Concepts, but still automatically convert the code into a variant that can also run on Micro Edition / Older JVM's ?

Scalability

• While the bundle lifecycle on the "activation" side is well defined now, the opposite end - unloading unused bundles seems to be murky on a number of levels.

Other Topics