If access to one mirror fails (at any point), automagically move on to the next (using one of the pluggable mirror selection techniques) Wayne Beaton

Avoid selecting a known-failed mirror on subsequent requests (for at least some configurable period of time) Wayne Beaton

Shared pool of plugins (multiple eclipse based products should be able to share the same bundles on disk).

Ability to process data on install (e.g. workspace metadata)

do you mean by that: metadata update? or preferences provisioning? or both? Philippe O.

Support for partial updates (aka fix packs)

would you see that go at a lower granularity than a bundle? Philippe O.

In an ideal world that would indeed be cewl. But what a release engineering mess would that cause if patches needed to be tracked on binary compatibility and such on an individual class basis (Erik.Vanherck@inventivedesigners.com)

The format of the descriptors should be based on an open standard for feeds that has author, copyright, update time, etc. and can have arbitrary XML payloads for encapsulating any data necessary Alex B.

Should be possible to open a web page in an internal browser and have Eclipse recognise that there are update sites mentioned like Firefox does; e.g. through use of 'link' protocols Alex B

headless (commandline) support should be either easy to create yourself, or the standalone update tool needs serious work. Server deployment, scripting, integration in 3th party tools like installers .. causes a need for this (Erik.Vanherck@inventivedesigners.com)

(perhaps obvious) only donwload as little as possible, binary diffs would be awesome, but that may be stretching it (Erik.Vanherck@inventivedesigners.com)

An option to save downloaded items in an archive for offline (re)installation. Richard Gronback

Ability to have symbolic names for URLs to update sites. I'm thinking of the current tag that controls where update manager looks for "updates for currently installed features". I'm thinking of two use cases, the first more important. David Williams

Currently, with the URL hardcoded by the installed feature, it is hard to do anything other than have it point to the location for official releases. Some would like to "update" from a release to a milestone, or from one milestone to the next milestone. It'd be much easier to do this, while still avoiding "accidental" updates to non-released code, to allow users to "override" the URL (pattern) for where to look for updates. (or example, a user might choose to change "webtools/updates" to "webtools/milestones" or even "webtools/weeklies".

The second use case is really simply a similar solution to a different problem. I've seen several cases where Eclipse projects forget to include an update site URL in their feature.xml. If this happens, nothing can be done until the user installs a new version. If there was some way for a user to associate a URL with a feature ID, then they could get maintenance updates without new installation.

Single Wizard user interface Wayne Beaton

Ensure that installation of patches does not invalidate currently installed units (features, etc) See Bug 167016 for a case where this fails in the current update manager. (DJ Houghton)

A simple way to add additional bundles to a configuration. For example, a user has a set of ad-hoc bundles that contain various tools, utilities, etc. They want to be able to add those bundles to an existing configuration without messing around with product extensions, links directories, etc. For example, just drag a bundle JAR into some place in an "update manager" dialog and have the bundle installed automatically. See bug 174517 for example. John Arthorne

On demand install: should be able to define a core installation of a product that users can download and try, and install other optional bundles/features as needed. This is particularly useful for large eclipse based products. Dorian Birsan

Distributed updates based on policies: Start on node A, if successful update next node, if successful update next node, etc. Eclipse on the server side is running in a clustered environment. Only one node should update itself at the same time. (Gunnar Wagenknecht)

Provisioning platform requirements

Separation metadata server / byte server

Flexible layout of bytes on the "byte server" (for example it is sometimes more interesting to download a big zip than many small zips)

Pluggable transports (Http, ftp, etc.)

Regardless of the transport there should be provision to support suspendable/resumable transfer of bytes, for those transports and byte servers that support it. Philippe O.

Support for authenticating proxy servers. Phill P.

Support for client/server authentication (https). Stefan L.

Metadata for grouping should have an extensible filtering mechanism (e.g. os=win32)

Ability to express dependencies on other things than bundles (e.g JRE >= 1.5).