[platform-update-dev] Issues we would like addressed in 3.0

["Dejan Glozic" <dejan@xxxxxxxxxx>]

The following is the list of items that will soon appear in the 3.0 draft
plan. We are posting it here to invite community discussion and to make
sure some important problems were not overlook. After that, we will post a
design document on how we intend to address them, and you (the community)
will be able to provide feedback. As some of the solutions start appearing
in regular integration builds, you will be able to play with the 'real
thing' and provide further corrective feedback.

Here are the items:

* Simplify the UI

User feedback indicates that Update UI is too powerful and occasionally
confusing to the majority of users. It needs to be simplified in order to
achieve the following: clear path for the most common tasks, progressive
disclosure, separation of update search from platform configuration tasks
and more economical use of real estate for properties.


* Addition of the operations API.

The intention is to push most of the business logic from the UI into this
new layer, thus providing APIs to perform most of the Update tasks headless
(Operations layer will be to Update Core what JFace is to SWT). The outside
perception of this addition is that scripted updates will become possible.


* Search improvements.

Search for features will be reworked. It will be pushed into the operation
layer, search APIs will be exposed and Update Core APIs will be modified to
make server-side search possible. A related work is to allow automated
searches i.e. searches that run unattended in the low-priority background
thread on startup or at scheduled intervals. The outside perception of this
change is performance (server-side search), refactoring (smaller code) and
ability to delegate search to custom site implementations. Additional
benefit is unattended (background) searches.


* Removal of the configuration state from the workspace.

Configuration state will not be stored in the workspace any more. Instead,
it will be inside the eclipse directory if possible (standalone install),
or user dir in shared install scenarios. Configuration state will therefore
be in a known location for external tools to find. The loss of function
(ability to have different features enabled in different workspaces) will
be solved by introducing several named configurations that can be used. The
configurations themselves would be saved centrally - only their names would
be in the workspaces.



* Feature uninstall.

Update will track features and plug-ins installed by it (as opposed to
native installers) and will be able to physically remove them later.
Removal of the configuration state from the workspace will make usage
analysis possible.



* Network operations robustness.

Networking code in Update will be reworked to provide for tighter control
and better performance. Where possible, multiple archives will be
downloaded in parallel to avoid single-socket bottleneck. We will also
investigate restartable downloading for very large archives.



* Automatic one-click update to eclipse integration builds.

Update and PDE will jointly provide necessary function to make a one-click
update to a new development driver. The support would involve conversion to
four-part versions on the fly (major.minor.service.CVS-version) and
required changes in the workspace to switch self-hosting to the updated
driver.



* Staging support.

Update will provide ability to create proxy subset of the remote update
site. Local administrators would use it to set local LAN sites for product
updates in cases where there are many users of the same Eclipse product in
the organization. Local administrators would be able to declare 'supported
updates' (the ones hosted locally) and direct users to update from the
local site to conserve bandwidth and minimize download failures.



Dejan Glozic