> <tangent> > That said I must admit that I'm not super happy with this solution since > to > make such a "fetch only" operation usable, either the director would have > to expose a "fetch" operation (but it would also have to expose a > "install" > operation to solve the other pb mentioned by James), or one would have to > either author its own director (or at least extend the current one) which > is something we want to avoid. In the light of recent discussions with Tim > and others, I wonder if the director should not become just a planner that > returns a bunch on operations that needs to be performed. The results of > this planner would then be passed on to the engine and a "target" phase > could be specified. For example: > EngineOperation[] op = director.install(ius, profile1) > engine(op, "fetch"); //This means do the operations but stop at > fetch. > </tangent>
This actually makes a lot of sense to me. It addresses multiple concerns including being able to present to the user an accurate statement of how much work needs to be performed, as well as allowing for much easier re-use in server-side scenarios. > Do you mean that some operations must be done with the actual user being > identified? > > <tangent id="2"> While probably not where you were going with this one, mentioning per-user operations reminded me of another flow we were planning to support in Maya where some software would only be available to certain users. If we were using user-aware repositories as part of the resolution process, would we do the filtering inside the repository? If so, how would we handle this in a multi-user scenario especially when a director/planner is being used server-side? Ideally I'd like the flexibility of filtering which software is available to which user, but currently the implementation / APIs do not allow passing of any handle or request-identifier to the repositories to aide in determining which software is available. Thoughts? </tangent>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
