Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "E4/Eclipse Application Services"

< E4
(Advanced)
(Marked as obsolete)
 
(19 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
a.k.a. "the twenty things"
 
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 [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], and make it possible to solve the [[Architecture Council/Minutes May 15 2008#Too Many Listeners|Too Many Listeners]] problem.
+
{{caution|This page is obsolete|See [[Eclipse4]] for updated information.}}
 +
 
 +
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.
 
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.
Line 8: Line 10:
 
Structuring them as individual services also makes it easier to use them from other languages / environments such as e.g. JavaScript.
 
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.
+
All of the services below are described from the point of view of an individual component. Under [[E4/EAS/Life Cycle|Life Cycle]], we explain how components are initialized, disposed, and how they are passed references to the services they require.
  
 
= Application Services =
 
= Application Services =
Line 18: Line 20:
 
!width="25%"|Status
 
!width="25%"|Status
 
|-
 
|-
| [[E4/EAS/Life Cycle|Life Cycle]]
+
| [[E4/EAS/Model Service|Acess to application model]]
| A defined path of initialization and disposal for components.
+
| Clients need to be able to retrieve model elements to access the current state of the application or to change this state.  
 
| High
 
| High
| [[Image:Progress.gif]] Use JSR-250 annotations (@PostConstruct/@PreDestroy) for Java case. Not clear how to advance on JS side.
+
| [[Image:Ok_green.gif]] EModelService API completed (can be used by injection).
 
|-
 
|-
| [[E4/EAS/Authentication|Authentication/Single Sign-on]]
+
| [[E4/EAS/Preferences|Reading/Writing of Preferences]]
| 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.
+
| Clients need to be able to retrieve preferences (and sometimes, change preferences) regardless of where the preferences are stored.
 
| High
 
| High
| [[Image:Error.gif]] No progress.
+
| [[Image:Ok_green.gif]] Simplified client API (preferences by injection) completed.  Provider-side API uses the 3.x API.
 
|-
 
|-
| [[E4/EAS/Status Handling|Status Handling]]
+
| [[E4/EAS/Adapting Objects|Adapting Objects]]
| Need a consistent way for components to report warnings / unexpected errors.
+
| The adapter pattern should be supported.
 
| High
 
| High
| [[Image:Glass.gif]] Clients should be able to use DI to inject a status handler for handling statuses, see org.eclipse.e4.core.services.IStatusHandler.
+
| [[Image:Ok_green.gif]] Simplified client API completed.  Provider-side API and more complex scenarios use IAdapterManager API.
 
|-
 
|-
 
| [[E4/EAS/Logging and Tracing|Logging and Tracing]]
 
| [[E4/EAS/Logging and Tracing|Logging and Tracing]]
 
| Components should be able to easily access a logger or provide tracing mechanisms to help with debugging.
 
| Components should be able to easily access a logger or provide tracing mechanisms to help with debugging.
 
| High
 
| High
| [[Image:Glass.gif]] 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.
+
| [[Image:Glass.gif]] Simplified client API backed by multiple loggers.  Work to be completed via {{bug|298660}}
 
|-
 
|-
| [[E4/EAS/Extension Registry|Extension Registry]]
+
| [[E4/EAS/String Localization|String Localization]]
| Registering and accessing extensions and extension points.
+
| The Eclipse Platform needs to ensure that localization can easily be done by product teams.
 
| High
 
| High
| [[Image:Question.gif]] 3.x version would be IExtensionRegistry, does this need to be updated?
+
| [[Image:Glass.gif]] The need for 4.0 is come up with a story for externalizing strings in the model xmi.  See {{bug|226340}} and {{bug|244468}} for more information.
 
|-
 
|-
 
| [[E4/EAS/Progress Service|Scheduling Work/Reporting Progress]]
 
| [[E4/EAS/Progress Service|Scheduling Work/Reporting Progress]]
 
| A component should be able to schedule work in the foreground or in the background.
 
| A component should be able to schedule work in the foreground or in the background.
 
| High
 
| High
| [[Image:Error.gif]] 3.x variant is IProgressService, IRunnableWithProgress, and Jobs framework.
+
| [[Image:Error.gif]] Deferred to 4.1.  In 4.0, clients should use equinox futures, IRunnableWithProgress, JFace Modal Context, and Jobs framework. Some cleanup work to be done in {{bug|304244}}
 
|-
 
|-
| [[E4/EAS/Preferences|Reading/Writing of Preferences]]
+
| [[E4/EAS/Status Handling|Error (Status) Handling]]
| Clients need to be able to store preferences on a variety of backends.
+
| Need a consistent way for components to report warnings / unexpected errors.
 
| High
 
| High
| [[Image:Glass.gif]] Lots of existing preferences stories in 3.x, very confusing to API consumers.
+
| [[Image:Ok_green.gif]] Simplified client API with providers using 3.x API.
 
|-
 
|-
| [[E4/EAS/Status Reporting|Status Reporting]]
+
| [[E4/Commands|Commands/Handlers]]
| 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.
+
| Clients should be able to register handles for global commands like cut/copy/paste.
 
| High
 
| High
| [[Image:Error.gif]] No progress.
+
| [[Image:Ok_green.gif]]  
 
|-
 
|-
| [[E4/EAS/String Localization|String Localization]]
+
| [[E4/EAS/Eventing System|Eventing System]]
| The Eclipse Platform needs to ensure that localization can easily be done by product teams.
+
| Clients should be able to monitor events easily without having a myriad of different kinds of listeners.
 
| High
 
| High
| [[Image:Glass.gif]] See {{bug|226340}} and {{bug|244468}} for more information.
+
| [[Image:Progress.gif]] See {{bug|288999}}.
 
|-
 
|-
| [[E4/EAS/Adapting Objects|Adapting Objects]]
+
| [[E4/EAS/Undo Redo|Participating in Undo/Redo Support]]
| The adapter pattern should be supported.
+
| 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
 
| High
| [[Image:Question.gif]] 3.x version would be IAdapterManager, does this need to be updated?
+
| [[Image:Error.gif]] Deferred to 4.1.  In 4.0, clients should use the operations framework in org.eclipse.core.commands.  Some cleanup work to do to describe the "pure 4.0" story is tracked in {{bug|315703}}
 
|-
 
|-
| [[E4/Commands|Commands/Handlers]]
+
| [[E4/EAS/Authentication|Authentication/Single Sign-on]]
| Clients should be able to register handles for global commands like cut/copy/paste.
+
| 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
 
| High
| [[Image:Progress.gif]] 3.x version would be ICommandService, IHandlerService, etc. e4 will have ECommandService, EHandlerService, and others.
+
| [[Image:Error.gif]] Deferred to 4.1.
 
|-
 
|-
| [[E4/Event Processing|Eventing System]]
+
| [[E4/EAS/BiDi|BiDi]]
| Clients should be able to monitor events easily without having a myriad of different kinds of listeners.
+
| A means for processing strings for display in non-LTR languages.
 
| High
 
| High
| [[Image:Progress.gif]] See {{bug|288999}}.
+
| [[Image:Glass.gif]] Need to determine if existing 3.x support is enough.
 
|}
 
|}
  
Line 86: Line 88:
 
!width="25%"|Status
 
!width="25%"|Status
 
|-
 
|-
| Receiving Input
+
| [[E4/EAS/Part Input|Receiving Input]]
 
| Model objects (parts?) should be able to define an input.
 
| Model objects (parts?) should be able to define an input.
 
| High
 
| High
| [[Image:Error.gif]] In 3.x, an editor has an IEditorInput.
+
| [[Image:Progress.gif]] DI can be used to define an input similar to consuming selection.
 
|-
 
|-
 
| [[E4/EAS/Selection|Providing Selection Information]]
 
| [[E4/EAS/Selection|Providing Selection Information]]
Line 105: Line 107:
 
| High
 
| High
 
| [[Image:Error.gif]] 3.x version would be JFace's AbstractResourceManager and friends.
 
| [[Image:Error.gif]] 3.x version would be JFace's AbstractResourceManager and friends.
|-
 
| [[E4/EAS/Undo Redo|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
 
| [[Image:Error.gif]] 3.x version would be IWorkbenchOperationSupport.
 
 
|-
 
|-
 
| [[E4/EAS/Saveable Life Cycle|Participating in Editor/Saveable Part Life Cycle]]
 
| [[E4/EAS/Saveable Life Cycle|Participating in Editor/Saveable Part Life Cycle]]
 
| Management of dirty state, save management, prompting to save unsaved resources, etc.
 
| Management of dirty state, save management, prompting to save unsaved resources, etc.
 
| High
 
| High
| [[Image:Error.gif]] No progress.
+
| [[Image:Progress.gif]] A save handler will invoke a doSave() method on a part's implementing client object directly.
 
|-
 
|-
| Updating UI Elements
+
| [[E4/EAS/Updating UI Elements|Updating UI Elements]]
 
| Components should be able to modify model objects directly and the UI should update if necessary  
 
| Components should be able to modify model objects directly and the UI should update if necessary  
 
| High
 
| High
| [[Image:Error.gif]] No progress. Tie in with 3.x databinding APIs?
+
| [[Image:Progress.gif]] The client should modify model objects directly and they should update the UI.
 
|-
 
|-
 
| [[E4/EAS/Notifications|Notifications]]
 
| [[E4/EAS/Notifications|Notifications]]
Line 125: Line 122:
 
| High
 
| High
 
| [[Image:Error.gif]] No progress. See [[Platform UI/Notifications]] for ideas.
 
| [[Image:Error.gif]] No progress. See [[Platform UI/Notifications]] for ideas.
 +
|-
 +
| [[E4/EAS/Status Reporting|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
 +
| [[Image:Error.gif]] No progress. Can we merge this one with "Notifications"?
 +
|-
 +
| [[E4/EAS/Part Service|Part Service]]
 +
| Clients need to be able to perform simple part-related operations like "bring to top", "activate", and "show part X".
 +
| High
 +
| [[Image:Progress.gif]] {{bug|295003}} Seems to be related to "Show In".
 
|}
 
|}
  
Line 137: Line 144:
 
| Dialogs/Windows need to be parented off of the proper window.
 
| Dialogs/Windows need to be parented off of the proper window.
 
| High
 
| High
| [[Image:Error.gif]] In 3.x there is JFace's IShellProvider interface. Also see {{bug|231150}}.
+
| [[Image:Error.gif]] In 3.x there is JFace's IShellProvider interface. Also see {{bug|231150}} and {{bug|303132}}.
 
|-
 
|-
| Reacting [[E4/Workbench Model|Workbench Model]] Changes.
+
| Reacting to [[E4/Workbench Model|Workbench Model]] Changes.
 
| Clients should be able to listen for changes in the workbench model.
 
| Clients should be able to listen for changes in the workbench model.
 
| High
 
| High
Line 147: Line 154:
 
| 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.
 
| 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
 
| High
| [[Image:Error.gif]] In 3.x, there is the IDecoratorManager and an extension point for contributing decorators.
+
| [[Image:Error.gif]] Deferred to 4.1.  For 4.0, decorations are only available via the compatibility layer, which uses the 3.x IDecoratorManager and an extension point for contributing decorators.
 
|-
 
|-
| Reacting to Changes to the Context
+
| [[E4/EAS/Context Change|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.
 
| The Eclipse Platform needs to be able to react to bundles coming and going on-the-fly at runtime.
 
| High
 
| High
| [[Image:Glass.gif]] 3.x version would be the IExtensionTracker. For an IEclipseContext, there are the runAndTrack(*) methods.
+
| [[Image:Error.gif]] Deferred to 4.1.  3.x version would be the IExtensionTracker.
 
|-
 
|-
 
| Dynamically Contributing to the [[E4/Workbench Model|Workbench Model]]
 
| Dynamically Contributing to the [[E4/Workbench Model|Workbench Model]]
 
| Clients should be able to add tool items, menus, parts, and other such model objects to the workbench.
 
| Clients should be able to add tool items, menus, parts, and other such model objects to the workbench.
 
| High
 
| High
| [[Image:Error.gif]] In 3.x, this would be like the IMenuService.
+
| [[Image:Progress.gif]]Boris to review what's there
 
|-
 
|-
| Object Contributions
+
| [[E4/EAS/Object Contributions|Object Contributions]]
 
| Actions that can be contributed to objects of a certain type.
 
| Actions that can be contributed to objects of a certain type.
 
| High
 
| High
| [[Image:Error.gif]] No progress.
+
| [[Image:Progress.gif]] Boris to review what's implemented
 
|-
 
|-
 
| [[E4/EAS/Focus Service|Focus Service]]
 
| [[E4/EAS/Focus Service|Focus Service]]
Line 210: Line 217:
 
** OSGi Stuff (NLS, ServiceTracker, Bundle States / Activator / Classloader; Log; State Location)
 
** 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)
+
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.
 
+
= Notes from e4 break out session =
+
* Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
+
**Does Views and Editors belong to that list?
+
  
 +
= Thoughts, Comments and Discussion =
  
 
'''Data model (a rest service)'''
 
'''Data model (a rest service)'''
Line 236: Line 240:
 
  - logging
 
  - logging
 
  - usage monitoring
 
  - 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 [[E4/Commands | 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]]''':
 
* '''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.
 
** 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 [[Architecture Council/Minutes May 15 2008#Getting rid of Singletons|Getting rid of Singletons]]
 
** <s>Mik to write Position Papers on new '''Focus Service''' and '''Notification Service'''</s>
 
** Application Model is related to almost all other architectural topics ([[Architecture Council/Minutes May 15 2008#Too Many Listeners|Too Many Listeners]], [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], [[Architecture Council/Minutes May 15 2008#Dependency Injection|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]]
 

Latest revision as of 15:06, 7 April 2011

a.k.a. "the twenty things"

Stop.png
This page is obsolete
See Eclipse4 for updated information.


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.

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.

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.

Application Services

Core

Name Description Priority Status
Acess to application model Clients need to be able to retrieve model elements to access the current state of the application or to change this state. High Ok green.gif EModelService API completed (can be used by injection).
Reading/Writing of Preferences Clients need to be able to retrieve preferences (and sometimes, change preferences) regardless of where the preferences are stored. High Ok green.gif Simplified client API (preferences by injection) completed. Provider-side API uses the 3.x API.
Adapting Objects The adapter pattern should be supported. High Ok green.gif Simplified client API completed. Provider-side API and more complex scenarios use IAdapterManager API.
Logging and Tracing Components should be able to easily access a logger or provide tracing mechanisms to help with debugging. High Glass.gif Simplified client API backed by multiple loggers. Work to be completed via bug 298660
String Localization The Eclipse Platform needs to ensure that localization can easily be done by product teams. High Glass.gif The need for 4.0 is come up with a story for externalizing strings in the model xmi. See bug 226340 and bug 244468 for more information.
Scheduling Work/Reporting Progress A component should be able to schedule work in the foreground or in the background. High Error.gif Deferred to 4.1. In 4.0, clients should use equinox futures, IRunnableWithProgress, JFace Modal Context, and Jobs framework. Some cleanup work to be done in bug 304244
Error (Status) Handling Need a consistent way for components to report warnings / unexpected errors. High Ok green.gif Simplified client API with providers using 3.x API.
Commands/Handlers Clients should be able to register handles for global commands like cut/copy/paste. High Ok green.gif
Eventing System Clients should be able to monitor events easily without having a myriad of different kinds of listeners. High Progress.gif 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 Error.gif Deferred to 4.1. In 4.0, clients should use the operations framework in org.eclipse.core.commands. Some cleanup work to do to describe the "pure 4.0" story is tracked in bug 315703
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 Error.gif Deferred to 4.1.
BiDi A means for processing strings for display in non-LTR languages. High Glass.gif Need to determine if existing 3.x support is enough.

User Interface

Name Description Priority Status
Receiving Input Model objects (parts?) should be able to define an input. High Progress.gif 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 Progress.gif 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 Error.gif 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 Error.gif 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 Progress.gif 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 Progress.gif 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 Error.gif 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 Error.gif 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 Progress.gif bug 295003 Seems to be related to "Show In".

Advanced

Name Description Priority Status
Shell Provider Dialogs/Windows need to be parented off of the proper window. High Error.gif In 3.x there is JFace's IShellProvider interface. Also see bug 231150 and bug 303132.
Reacting to Workbench Model Changes. Clients should be able to listen for changes in the workbench model. High Progress.gif 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 Error.gif Deferred to 4.1. For 4.0, decorations are only available via the compatibility layer, which uses the 3.x 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 Error.gif Deferred to 4.1. 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 Progress.gifBoris to review what's there
Object Contributions Actions that can be contributed to objects of a certain type. High Progress.gif Boris to review what's implemented
Focus Service It should be possible to drive and enhance the presentation of the model/workbench based on the current "focus". High Error.gif No progress.

Domain-Specific

Name Description Priority Status
Workspace/Resources Components should be able to create folders and files via interacting with the user's workspace. High Error.gif No progress. 3.x API in the org.eclipse.core.resources bundle.
Database Connection N/A High Error.gif No progress.
Getting Hold of the Domain Model Clients should be able to retrieve the model, say, in the form of an EMF model. High Error.gif 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:
    • 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)

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

Command Bus (a javascript function)

- 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.

Back to the top