Difference between revisions of "E4/Eclipse Application Services"

Revision as of 13:40, 16 January 2009

a.k.a. "the twenty things"

This is a first 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, foster Becoming More Asynchronous, and make it possible to solve the Too Many Listeners problem.

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.

We believe that these services should be offered as separate, independent APIs, so that clients can make use of some of them without having to buy into all of them. Structuring them as individual services also makes it easier to use them from other languages / environments such as e.g. JavaScript.

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.

Fundamentals

• Life Cycle - initialization and disposal.
• Authentication (single sign on)
• Status Handling (errors and warnings).
• Logging over and above status handling.
• Extension Registry. Registering and accessing extensions and extension points.
• Scheduling Background Work. Schedule work in a way that is visible to the user.
• Accessing Preferences (mostly read access, but sometimes write access).
• Reporting Status (think status line).
• String Localization.
• Adapting Objects. Adapt an object (typically, the current selection) to a type that is relevant to the current plug-in.

Specific to UI Parts

• Receiving Input.
• Producing Selection.
• Persisting Data. Receiving persisted state, and producing persistable state (typically UI state), such as e.g. layouts, dialog sizes, viewer selection and expansion state.
• Managing Shared Resources (e.g. JFace LocalResourceManager).
• Connecting to the Help system.
• Participating in Undo/Redo.
• Participating in Editor Lifecycle (units of saveability, dirtiness, saving, prompting to save).
• Updating UI Elements such as e.g. enablement, labels, icons of menu and tool items.
• Registering handlers for Commands. For example, register a handler for a global command like Copy/Paste.
• Notifications. Inform the user of events in the application that may require attention, whether or not the application is visible.

Specific to Command Handlers

• Reporting Progress including responding to cancellation requests.

Advanced

• Shell Provider (for properly parenting dialogs).
• Reacting to changes to the workbench model.
• Participating in label and icon Decoration.
• Reacting to changes to the Context (such as plug-ins that come and go). Ability to react to components coming and going at runtime.
• Dynamically contributing to the Workbench Model (e.g. tool items, menus, sub-parts).
• Object Contributions. Actions that can be contributed to objects of a certain type.
• Focus Service. Enabling a task-focused interface.

Domain-specific

• IWorkspace.
• Database connection.
• Getting hold of the domain model, e.g. in the form of an EMF model.

Not Sure About These

• String comparison/collation.
• "Show In" support.
• Hyperlink detection.

Other Services not yet Decided on

• From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
  • Capabilities
  • Content Types, Associations
  • Markers
  • 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)

• The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)

Notes from e4 break out session

• Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
  • Does Views and Editors belong to that list?

Data model (a rest service)

- Adapting object
- Selection (currentSelection)
- UI Contributions
- Decorations
- Common UI Elements
- Persist State 
- Extension Registry
- roles

Command Bus (a javascript function)

- Selection (change)
- Undo/Redo
- Handlers
- Dynamic enablement
- Notification Service
- Focus service
- logging
- usage monitoring

Comments and Discussion

Kevin McGuire - Some of these support a component model, and some provide an application framework of common elements. It'd be worthwhile to identify this split since the former are essential for a web based Eclipse component model. For example, Selection service is needed so one can write independent views/editors and have them work together. Without it, there's no component interaction. Similarly, IMenuService and commands allow fine grain component interaction, so one plugin can say add a menu to a view it doesn't know about. UI State persistence though can be supported in a number of ways. Help is purely an application framework item.

Kevin McGuire - We should have Commands as a top level item although we have an entire subject page on commands. Plus here need to tie commands in with menu service and handlers (not sure right organization)

• 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.
  • Especially when Services go on the Server (Sessions, Macros Recording), need a consistent Story for exposing a Service, its state and commands, need to be Getting rid of Singletons
  • Mik to write Position Papers on new Focus Service and Notification Service
  • Application Model is related to almost all other architectural topics (Too Many Listeners, Becoming More Asynchronous, Dependency Injection, Sessions, Macro Recording)

Bjorn asks: where is the list of the global commands? Do we have a namespace of commands? Can any plug-in contribute to the set of commands? How do we know what the semantics of a given command are? -- See also E4/Commands