|
|
| (183 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | = Week of 20070813 =
| + | #REDIRECT [[Equinox/p2/Meetings]] |
| − | | + | |
| − | == Agenda==
| + | |
| − | | + | |
| − | * Separation of concerns around the artifact repository (https://bugs.eclipse.org/bugs/show_bug.cgi?id=197644).
| + | |
| − | * Shared install:
| + | |
| − | ** How much of the things noted in the discussion (http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02692.html) are provisioning related vs runtime related (location of preferences, log files, cache, etc.)
| + | |
| − | * Controlling the Engine:
| + | |
| − | ** The engine currently takes an operation to install, or uninstall IUs. Can this separation of installation / uninstallation / update / etc. be kept? How do we reconcile?
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | | + | |
| − | * DJ Houghton
| + | |
| − | * Jeff McAffer
| + | |
| − | * Simon Kaegi
| + | |
| − | * Pascal Rapicault
| + | |
| − | * John Arthorne
| + | |
| − | * Susan McCourt
| + | |
| − | * Dave Stevenson
| + | |
| − | * James Miles
| + | |
| − | * Patrick Dempsey
| + | |
| − | * Stefan Liebig
| + | |
| − | * Ted ??
| + | |
| − | * Joe ??
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | === Artifact repository ===
| + | |
| − | | + | |
| − | We need to be able to perform post-processing steps after download, such as unpack-200, re-assembling compressed deltas. Should the repository be aware of these post-processing steps, or should it be done independently? When mirroring between repositories, some post-processing steps are not necessary (for example unpacking zips/jars
| + | |
| − | | + | |
| − | In our discussion, we distinguish between original bytes (as they are added to the repository from build system), and stored bytes (the actual bytes stored on disk in the repository). When mirroring between repositories it is more efficient to directly mirror the stored bytes, rather than the original bytes.
| + | |
| − | | + | |
| − | We should have different artifact descriptors for each available representation of an artifact (jarred version, delta compressed version, etc). Leave it up to download manager or some other entity on the client to decide which artifact descriptor it wants to load for its current circumstances. The artifact key uniquely identifies the original bytes, whereas the artifact descriptor identifies various flavors of stored bytes.
| + | |
| − | | + | |
| − | Two main methods for artifact repository API: getArtifactBytes(IArtifactKey), returning the "original bytes", and getArtfactDescriptors(IArtifactKey), which returns all the available descriptors corresponding to the given key.
| + | |
| − | | + | |
| − | === Shared Install ===
| + | |
| − | | + | |
| − | Discussion skipped because Andrew Overholt is leading this work and wasn't present
| + | |
| − | | + | |
| − | === Engine discussion ===
| + | |
| − | | + | |
| − | Want to be able to pass a batch of operations to the engine at once.
| + | |
| − | | + | |
| − | Currently the interesting units are ProvisioningOperand and Phase. An EngineOperation just provides an ordered list of phases. The operands actually provide the interesting behavior (install, uninstall, update).
| + | |
| − | | + | |
| − | Could we specify instead in terms of states, and an operation is just a request to transition from one state to another. The precise phases required for that state transition are implementation details.
| + | |
| − | | + | |
| − | [[Category:Equinox|Provisioning Weekly Discussion Topics]] | + | |
| − | [[Category:Provisioning|Weekly Discussion Topics]]
| + | |
