Requirements for a new update manager

This page lists requirements for a new provisioning story. It volunteerly avoids the mention of any specific technology.

Functional requirements

• Provision bundles as well as "root files" (startup.jar, exe, etc.)
• Provision groups of bundles
• Provision single bundles
• Provision non running configuration (manage multiple configurations)
• Check the validity of the system before installing (a user should know whether the bundles it installs will resolve or not)
  • But allow, on user's choice, the ability to "install anyway", since the user may be doing things "out of order", or may "know what they are doing" so an invalid system is not fatal. David williams.us.ibm.com 02:46, 10 October 2006 (EDT)
• Transparent provisioning of dependent bundles (in case of a mismatch, missing dependencies should support be updated)
• Support rollback in case of failure during the install
• Support deletion of old bundles after successful install. Phill P.
• Transparent support for mirrors
  • including the ability to support various pluggable mirror selection techniques (i.e. locale, round robin, speed, etc) Philippe O.
• 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)
• Integrate nicely with JNLP deployed systems
• Integration with other provisioning technologies
• Support bundle level configurability (set bundle start level, auto start, ini file)
• A simple update API for use in RCP applications. Phill P.
• 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"

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.
• 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).
  • When metadata are used to express filtering or dependencies, they should have at least the same expressing power of OSGi related mechanisms.Philippe O.
• NLS support for metadata
• Extensible metadata

Tooling

• Ability to generate part of the metadata from bundle level dependencies
• Ability to check and issue warnings when dependencies are expressed on things which are packaged by others Philippe O.