Difference between revisions of "Requirements for a new update manager"

Revision as of 03:55, 3 October 2006

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)
• 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.
• 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

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.