E4/Vision

Vision, Requirements, Goals and Constraints

It'll help to come up with Vision of what E4 is that's backed and shared by everyone working on it. This doesn't need to remain static, but we should always be clear where we're heading.

The write-up here is just some initial seeding ideas. I'm sure that the Group can come up with some much better definition at the Summit.

Vision

• Grow adoption of Eclipse also where UI's other than IDE-like are needed (browser, skins, css, ...)
• Make Eclipse 4.0 darn cool!
• Make the products built on Eclipse 4.0 be perceived as slick, modern, up-to-date thanks to the Framework
  • Make Eclipse the #1 choice for integrating tools of any kind from small to huge installation bases
• Make E4 a big success based on a Real Community Effort
• Make Eclipse on the serverside as visible and attractive as RCP is already on the client

Goals

• Reduce bloat (number of classes, memory footprint)
  • Improve Performance compared to Eclipse 3.4 in spite of added functionality:
    • e.g. 10% faster startup of empty SDK; 10% less memory footprint after opening Preferences; 10% faster Performance on Average
  • Have a plan for no longer recommended APIs, clear communication (i.e. deprecation) on what is no longer recommended
• Come up with a core architecture that's small, efficient, slick, has a Metamodel, supports client/server split and can carry Eclipse for the next 10 years
  • Improve Reliability (thanks to common well-defined architecture, e.g. for concurrency)
• Simplify adoption of Eclipse in large, deployment and management in multi-user client-server centrally administrated environments (Preferences, Role-based Access, ...)
• Address some of the most wanted "Really hard" problems that are beyond scope in a .x release (Flexible Resources, Macro Recording, Role-based Access; ...)
  • Bugzilla had about most wanted enhancements / most hated bugs; but I currently only find Statistics about new bugs; anybody knows where to find the others?

Requirements

• Support running in a Browser.
  • Support running what in a browser? Just RCP/pure SWT apps? The IDE itself?
• Provide a Metamodel of the Workbench (with Introspection etc)
• Support Macro Recording and Playback.
• Support Team-shared Preferences.
• Support user role-based access permissions
• Support a Flexible Resource Model that covers all the needs of non-Eclipse Legacy Software

Constraints

• Remain backward compatible wherever possible
• Be Open and Transparent through the entire course of the project

Non-Requirements / Non-Constraints

It sometimes helps setting direction when thinking about what we do NOT want to achieve, like

• Do not define ourselves in terms of what the competition does (Netbeans, Visual Studio, ...?).
• Be not the dumping ground for any kind of feature work that seems too hard for a single individual -- there will be a number of non-E4 (Eclipse 3.5 / 3.6) feature additions on the "old" Stream