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

["Peter Manahan" <manahan@xxxxxxxxxx>]

A few extra's and comments to the existing ones. 

* More Helpful Error Messages 
  -  Currently the error messages returned by Update Manager are really, really bad. 
    ex.When a feature can't be installed because a required feature is missing the 
    error is "Cannot install because the configuration would be invalid." This is extremely
    confusing to users. 

* Rollback. 
-  This is really important. It ties in to the uninstall below. Users may be required to revert
   back to a previous version. Currently (and this may change as a result of the some of 
   the other items below) after installing say a new version of a feature and switching
   workspaces even if reverted in the previous workspace it shows up again in the new one.
  
*Headless/silent installs of updates
 - in a corporate environment where 1 team would upgrade several hundred workstations 
   overnight. This is one of the major complaints customer have with our eclipse
   based products.

*Site level requires.
 -  What you have installed/configured would affect the visibility of which features 
    would available. So if i had the JDT installed my new refactoring feature would only 
    show up to the user in that case. If the JDT was missing they wouldn't see it at all 
    
* Impact Analysis (better integration with native installers basically)
  - sometimes native installers may want to remove function from eclipse which they
    laid down. They need a way to ask eclipse if it is 
   a) ok to add or remove a feature
   b) if it isn't ok some information that could be provided to the user to assist
      in making the decision regarding uninstall.

* In optional-features dialog, don't show choices that cannot work 
 -  like optional pieces that don't exist on the server hence can never be a 
    valid choice to be installed.

* Features are important too 
  a) From a product point of view, features are what teams talk about
  b) From the user point of view, they use features not plugins (ie JDT)
  c) From the installation point of view, features get installed and are what the 
     prereqs are against. plugins are just along for the ride.
  d) From support point of view features are what get supported (ie. XML editor is broken).
     
  e) From developer point of view plugins are more important
    
   a+b+c+d > e  unless you are a developer of a plugin :-)

  For everyone that has to use/create/install/support products features are the primary
  unit. Plugins are just building blocks. 
  The idea that a feature with a specific prereq set of plugins would "invisibly" still
  run after applying another feature with the same plugin (this is a support/product nightmare)
  is just plain wrong. Products don't care about the runtime details of eclipse. They want the XML
  editor to work and be supported and not to be submarined by rogue plugin from another product.

  In essence the requirement is that features "dictate" what is available at runtime. 
  - when a feature is disabled its plugins are also disabled. 
  - A plugin breaks the version prerequists on a feature should cause the complete feature
    to be disabled along with other plugins it contains. 
  - Features are the unit by which eclipse function is delivered.

  We are forced to have duplicate prerequisite matching (which still doesn't catch everything)
  because the well defined installable features can be broken by the runtime plugin loading resolution.
  The prerequisites should only really need to be on the features. And the runtime should resolve 
  the features not the plugins. (From the a+b+c+d point of view above) 


--------Comments to the previously posted items.

* Simplify the UI
- One place that could use improvement is the one-click update. It would be nice
  if there was a way to have an information/"More Info" button so the user can 
  see what the update contains before they decide to take it. 

* Addition of the operations API.
- Overall this would be the preferred way to install features into eclipse. We'd like to
  see the base platform laid down say via a native installer then "deploy" 
  features/function into it. 

* Search improvements.
- 

* Removal of the configuration state from the workspace.
- Finally :-). 
- For the shared scenario it would be nice to have shared and user config 
  spaces
- The separation of installation/update and configuration actions in the api's
  would be really useful.


* Feature uninstall.
- Similar comments above for the operations API. 

* Network operations robustness.
- restartable downloads for large updates would be great. We had to make a couple of large 
  updates (download first) then install  because of this.

* Automatic one-click update to eclipse integration builds.
- Products shipping with a version of eclipse will still be able to
  restrict the one-click update.




Thanks,

-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and 
Product Architecture
------------------------------------
manahan@xxxxxxxxxx

Dejan Glozic/Toronto/IBM@IBMCA Sent by: platform-update-dev-admin@xxxxxxxxxxx 04/30/2003 02:02 PM Please respond to platform-update-dev

To:        platform-update-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-update-dev] Issues we would like addressed in 3.0

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

_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev