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.

Missing Mechanism Bloat: The Too Many Listeners Problem, for instance, is a result of not having a proper mechanism in place. Boilerplate code like for Extension trackers seems an indication that some mechanism is missing.

API vs Non-API: See Gunnar's E-Mail and Kevin's response - Use the experience collected over the years to come up with good design decisions for allowing re-use vs. lock-in

Componentization: Get rid of stuff rarely used from the core framework where possible. Related to Nexus Project for mix-and-match of extending components on a more fine-granular level. P2 might help.

Too Many Events

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 the following (the "myself" variable is not actually needed but added here for clarity what the code actually does):