Difference between revisions of "Equinox p2 Engine"

Revision as of 10:56, 20 August 2007

This page contains random notes and questions about the Engine.

• Is the engine only invoked for provisioning related operations? For example could it be used to obtain the log file of a particular touchpoint.
  • For not the answer is no. The engine is only used for provisioning related operations.

• Operations that we need to invoke on the engine:
  • Reboot the targeted touchpoint.
  • Compute the size of things being downloaded. It would invoke the touchpoint to actually know whether or not the IU should be obtained.
  • Validation of checks contained in IUs
  • Qualification, for example discovery of an eclipse install

• Engine API:
  • The OSGi Deployment Admin service has an interesting API that we should mimic.
    • A mapping of some of the Deployment Admin concepts would require us to look at the API as acting on a single profile.
    • The Deployment Admin SPI has the concept of a DeploymentSession for holding the current state for deployment activity. This might be useful internally to track transactional state. It's not clear yet if we want to expose the transactionactional state in the public API however we should leave that option open.
  • The parameters passed to the engine does not give us flexibility for other operations than Install and Uninstall.
    • We still want to keep this grammar as small as possible: install / update / uninstall until we have concrete requirements for more operations.
    • We're currently passing a "single" operation and set of operands. We should move to a model where we pass a set of operations with internal operands. This allows us to "perform" a mixture of the various operations in a single call to the Engine.
    • The scope of an Engine "perform" command is a single profile and only one Engine provisioning session should be active on a profile at one time. This has some consequences for transactions that we will need to think about.

• IU processing:
  • Currently the processing is done breadth first, in that first all the IUs are being fetched, then they are all installed and finally configured. Is that too strict? Should we allow for some phases to specify how they should be run?
  • An IU may appear multiple times in an operation and may have different bindings (e.g. different IUs). This allows to process IUs being uninstalled in their "binding" of the past, and it allows to process IUs being installed with their "binding" of the future.
  • What is the order in which phases are executed when IUs are being installed and uninstalled.

• Phases:
  • We currently have two phases, fetch and install. We are thinking of introducing a third one, configure. We likely need others, which one? We should look at what is in SI/SPX and other specs.

• Transaction handling:
  • When multiple profiles are being modified in one operation, what is the scope of the transaction.