[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Issues we would like addressed in 3.0
|
Peter, thank you for your commants - they are going to be very useful to us
as we are shaping the 3.0 work items.
I have annotated your posting - my comments are enclosed in <DG></DG> (for
the benefit of users with plain ASCII mail readers).
Regards,
Dejan Glozic, Ph.D.
Manager, Eclipse Platform Components
D2/MY7/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4854
Peter
Manahan/Toronto/IBM@IBMCA To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@ Subject: Re: [platform-update-dev] Issues we would like addressed in 3.0
eclipse.org
05/06/2003 10:15 AM
Please respond to
platform-update-dev
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.
<DG>You are correct to suggest that Update state stored in the workspace is
the culprit.</DG>
*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
<DG>In other words, you want us to filter features available in the site by
only
showing those that can actually install (i.e. whose prereqs can be
satisfied in the product).
</DG>
* 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.
<DG>This is already available in 2.1. We want to go further and radically
redo the UI. In particular,
we want to get rid of the Update Manager as it is today (separate
install/update and configuration parts)
and make them simpler/easier to use/less intimidating.
</DG>
* 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.
<DG>We should have been more clear on this topic. The idea is to help
Eclipse developers by allowing them to jump to the next driver using
Update. This is not intended for Eclipse product users and will not allow
them to jump to the next driver of the product :-). We want to do this to
make Update more useful to ourselves, and 'eat our own food' i.e. improve
the quality of Update by ironing out all the remaining bugs through daily
use.
</DG>
Thanks,
-----------------------------------
Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture
------------------------------------
manahan@xxxxxxxxxx
Dejan
Glozic/Toronto/IBM@IBMCA To:
Sent by: platform-update-dev@xxxxxxxxxxx
platform-update-dev-admin@e cc:
clipse.org Subject:
[platform-update-dev] Issues we would like
addressed in 3.0
04/30/2003 02:02 PM
Please respond to
platform-update-dev
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
