E4/Eclipse Application Services
a.k.a. "the twenty things"
This is a list of "recommended APIs" - things that we expect most Eclipse plug-ins would make use of (if applicable). The goal is to reduce bloat by focusing on a smaller subset of core recommended Services and APIs. If these Services and APIs are also structured in a similar and consistent manner, it will also simplify understanding.
Note that "the Workbench", "PlatformUI" or "Platform" are not on this list. Think of which services you would want to use from within your contributed view or editor.
All of the services below are described from the point of view of an individual component. Under Life Cycle, we explain how components are initialized, disposed, and how they are passed references to the services they require.
|Reading/Writing of Preferences||Clients need to be able to retrieve preferences (and sometimes, change preferences) regardless of where the preferences are stored.||High||Lots of existing preferences stories in 3.x, very confusing to API consumers. Need to make the common case easy, while still allowing for more complicated cases like project-specific preferences etc.|
|String Localization||The Eclipse Platform needs to ensure that localization can easily be done by product teams.||High||See bug 226340 and bug 244468 for more information.|
|Adapting Objects||The adapter pattern should be supported.||High||3.x version would be the IAdapterManager, this will be split into client and provider APIs in e4 (bug 295396.|
|Error (Status) Handling||Need a consistent way for components to report warnings / unexpected errors.||High||Clients should be able to use DI to inject a status handler for handling statuses, see org.eclipse.e4.core.services.IStatusHandler.|
|Logging and Tracing||Components should be able to easily access a logger or provide tracing mechanisms to help with debugging.||High||Clients should be able to use DI to inject a logger/tracer, see org.eclipse.e4.core.services.Logger. Note that there is also the OSGi LogService. Can we merge this with Error Handling?|
|Scheduling Work/Reporting Progress||A component should be able to schedule work in the foreground or in the background.||High||3.x variant is IProgressService, IRunnableWithProgress, and Jobs framework.|
|Commands/Handlers||Clients should be able to register handles for global commands like cut/copy/paste.||High||3.x version would be ICommandService, IHandlerService, etc. e4 will have ECommandService, EHandlerService, and others.|
|Eventing System||Clients should be able to monitor events easily without having a myriad of different kinds of listeners.||High||See bug 288999.|
|Participating in Undo/Redo Support||Clients should be able to push operations to the undo/redo service and have it be tie in with other operations on the stack automatically.||High||3.x version would be IWorkbenchOperationSupport.|
|Authentication/Single Sign-on||A component should be able to request authentication in a way that the end user perceives as consistent. Different backends can have different requirements, will need to support multiple mechanisms.||High||No progress.|
|BiDi||A means for processing strings for display in non-LTR languages.||High|
|Extension Registry||Registering and accessing extensions and extension points.||High||3.x version would be IExtensionRegistry. Boris: With more and more information moving into the model, I don't think the extension registry belongs in this list.|
|Receiving Input||Model objects (parts?) should be able to define an input.||High||DI can be used to define an input similar to consuming selection.|
|Providing Selection Information||Different parts of the model should be able to react to current active selection of other parts.||High||DI can be used in this case. Currently the model would define 'selection' as a variable that is modifiable by an IEclipseContext. In 3.x there is ISelectionService.|
|Persisting State and Data||The user interface must be able to remember things like its size and layouts when it has been recreated.||High||In 3.x, IDialogSettings and IMemento is used.|
|Managing Shared Resources||There should be a mechanism to pool identical resources together and share them to keep memory footprint low.||High||3.x version would be JFace's AbstractResourceManager and friends.|
|Participating in Editor/Saveable Part Life Cycle||Management of dirty state, save management, prompting to save unsaved resources, etc.||High||A save handler will invoke a doSave() method on a part's implementing client object directly.|
|Updating UI Elements||Components should be able to modify model objects directly and the UI should update if necessary||High||The client should modify model objects directly and they should update the UI.|
|Notifications||Inform the user of events in the application that may require attention, regardless of whether the application is visible or not.||High||No progress. See Platform UI/Notifications for ideas.|
|Status Reporting||Users should be able to easily check the status of operations/requests. In 3.x this is done in the status line and the 'Progress' view.||High||No progress. Can we merge this one with "Notifications"?|
|Part Service||Clients need to be able to perform simple part-related operations like "bring to top", "activate", and "show part X".||High||bug 295003 Seems to be related to "Show In".|
|Shell Provider||Dialogs/Windows need to be parented off of the proper window.||High||In 3.x there is JFace's IShellProvider interface. Also see bug 231150.|
|Reacting to Workbench Model Changes.||Clients should be able to listen for changes in the workbench model.||High||See IEventBroker.|
|Participating in Label and Icon Decoration||Components should be able to contribute decorations to provide information to the user in a way that does not necessarily draw the user's attention.||High||In 3.x, there is the IDecoratorManager and an extension point for contributing decorators.|
|Reacting to Changes to the Context||The Eclipse Platform needs to be able to react to bundles coming and going on-the-fly at runtime.||High||3.x version would be the IExtensionTracker.|
|Dynamically Contributing to the Workbench Model||Clients should be able to add tool items, menus, parts, and other such model objects to the workbench.||High||In 3.x, this would be like the IMenuService.|
|Object Contributions||Actions that can be contributed to objects of a certain type.||High||No progress.|
|Focus Service||It should be possible to drive and enhance the presentation of the model/workbench based on the current "focus".||High||No progress.|
Not Sure About These
- String comparison/collation.
- "Show In" support.
- Hyperlink detection.
- Opening a web page. (Eclipse 3.x: IWorkbenchBrowserSupport)
Other Services not yet Decided on
- From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
- Content Types, Associations
- Workspace, Resources (related to Team Support)
- Launching Framework
- Core Variables / Launch String Substitution
- EFS (core.filesystem)
- OSGi Stuff (NLS, ServiceTracker, Bundle States / Activator / Classloader; Log; State Location)
There has been a discussion about if this list is too large. The conclusion is that you can build applications with subsets, but bigger applications usually need most of them. Instead of reducing the list further we want to make sure that in future there is only exactly one way to do a thing, not multiple as it is today.
Thoughts, Comments and Discussion
Data model (a rest service)
- Adapting object - Selection (currentSelection) - UI Contributions - Decorations - Common UI Elements - Persist State - Extension Registry - roles
- Selection (change) - Undo/Redo - Handlers - Dynamic enablement - Notification Service - Focus service - logging - usage monitoring
- From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
- Besides the List of Services we're compiling now by hand, we'll need a strong way of describing the Services for E4 -- as a medium for newcomers to understand Eclipse -- perhaps Tooling to make Service Descriptions machine readable / usable. In the beginning, Every Service should have a Wiki page describing it and the Architecture behind it (probably linked from this Summary Page.