Do you mean that some operations must be done with the actual user being
identified?
Yes, if you are sharing an install (multiuser), each user must be
configured separately. And to your point in <tangent 2> each user may be
managed differently.
<cotangent 2>
My thoughts were along these lines. Currently we have an IU with id "sdk"
in the sample. This sample provides no capabilities but only list
requirements to be installed. While it should remain an IU it should be
categorized by subclassing or creating an interface for all of these: IU
fragment, IU, etc. That would allow another abstraction that manages a
description ("sdk") of what can be installed. These could me managed on a
per user basis if that is what is wanted.
</cotangent>
"Tim Webb"
<[EMAIL PROTECTED]>
Sent by: To
equinox-dev-bounc "Equinox development mailing list"
[EMAIL PROTECTED] <[email protected]>
cc
08/16/2007 03:40 Subject
PM Re: [equinox-dev] [prov] Thoughts
on the engine
Please respond to
Equinox
development
mailing list
<[EMAIL PROTECTED]
pse.org>
<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
<<inline: graycol.gif>>
<<inline: pic00393.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
