|
|
| (171 intermediate revisions by 12 users not shown) |
| Line 1: |
Line 1: |
| − | = Week of 20070820 =
| + | #REDIRECT [[Equinox/p2/Meetings]] |
| − | == Agenda ==
| + | |
| − | * We need a lot of events, some are core to the functioning of the system, others are to help drive the UI. Currently we have our own event bus. Should we migrate to the osgi event service?
| + | |
| − | * Related to events, we need some event generation guidelines. See the concerns raised in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=199806 bug 199806].
| + | |
| − | * Naming. We have had some discussion around the naming of the work we are doing. Currently it is "The Equinox Provisioning support" or some such. This is very cumbersome for discussions, presentations, documents, ... The package name we've been using is o.e.equinox.prov.*. Before we get too too far we need a real name that we can live with through graduation. By the time of the meeting hopefully we will have had some discussion on the mailing list and be able to conclude with a decision.
| + | |
| − | * Carried over from last week's agenda: shared install
| + | |
| − | | + | |
| − | == Attendees ==
| + | |
| − | * Susan McCourt
| + | |
| − | * DJ Houghton
| + | |
| − | * Pascal Rapicault
| + | |
| − | * Simon Kaegi
| + | |
| − | * James Miles
| + | |
| − | * Andrew Overholt
| + | |
| − | * Thomas Watson
| + | |
| − | | + | |
| − | == Meetings ==
| + | |
| − | | + | |
| − | === Event handling ===
| + | |
| − | * The OSGi event service is not currently included in the SDK, so we would need to add it.
| + | |
| − | | + | |
| − | = Week of 20070813 =
| + | |
| − | | + | |
| − | == 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 Habeck
| + | |
| − | * Joe Rusnak
| + | |
| − | | + | |
| − | == Minutes ==
| + | |
| − | | + | |
| − | We initially attempted an Asterisk conference call, but the line quality was not acceptable. We moved all participants to a private number until we find an acceptable way to do a public call.
| + | |
| − | | + | |
| − | === 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.
| + | |
| − | | + | |
| − | Tangible next steps are to implement post-processing steps for pack200 and signature verification.
| + | |
| − | | + | |
| − | === Shared Install ===
| + | |
| − | | + | |
| − | Discussion skipped because Andrew Overholt is leading this work and wasn't present
| + | |
| − | | + | |
| − | === Engine discussion ===
| + | |
| − | | + | |
| − | Currently the engine API only allows a single operation to be performed at once. We may want to be able to pass a batch of operations to the engine and have them be performed together (atomically).
| + | |
| − | | + | |
| − | 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 the engine API 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.
| + | |
| − | | + | |
| − | On a multi-user install, some phases are no-ops because they have already been performed before by another user.
| + | |
| − | | + | |
| − | [[Category:Equinox|Provisioning Weekly Discussion Topics]]
| + | |
| − | [[Category:Provisioning|Weekly Discussion Topics]]
| + | |
