[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] Director API experiments
|
> - allow for download of the artifacts before doing configuration
Isn't this the collect phase you have now? I am not sure it is as I am still sifting through the phases and exactly what gets done with each. However it really is necessary to be able to be able to effectively choose which phases to run.
![Inactive hide details for Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]()
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
10/04/2007 10:01 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
Thx for the feedback Susan, I sympathize with the problems you raised.
Let me expose the dilema I'm faced with:
- We need to make sure that the simple things are simple, for example an
optimistic user who just want to install an IU should just have to call one
method (IDirector.install())
- We want to make sure more advanced scenarios are possible, for example a
user willing to cause the prefetch of the IUs before prompting for install
(IDirector2 +Engine)
But what I seem to hear here is that we would need another level of API
that would make the "not so advanced and relatively common things" easy to
do (e.g. size computation, prefetch, ???).
My problem with this approach is :
- more API to maintain
- what are the criteria to use to add something to this API?
- what is the way to factor this API to avoid unecessary coupling?
- if we put it all in one place, that would bring along too much stuffs
but as we are all lazy we would all be using this helper rather than the
part of the API we need thus bringing too much for our use case.
(note that currently some of the phases are not optimally placed wrt to
bundle)
So in clear, adding stuffs to DirectorResult is not something that I'm
thrilled with and having loads of helpers somewhere in the core code is not
great either.
For the time being I can help you author helpers that would reside in the
UI and once we understand the shape of these we can decide where they
belong. Note that I would think that they leave in the UI, because they are
specific to your usecases and we can probably make some assumptions about
the structure of the system and thus justify the coupling.
PaScaL
equinox-dev-bounces@xxxxxxxxxxx wrote on 10/03/2007 12:58:24 PM:
>
> Here is my first impression. I might change my mind later after
> working with it awhile.
>
> I like the idea of IDirector2 replacing IDirector and putting some
> helper methods somewhere that perform phases for me if I give them a
> DirectorResult. But it would be cool if it doesn't even feel like
> engine phases to a client. It's just an intermediary step to doing
> something....Once I have the result, I can do all kinds of cool
> things with it (actually perform it, or get the size, etc.).
>
> It also seems like the Oracle goes away and those methods become
> helpers, because the DirectorResult can be used to figure out
> whether I can install, whether there are updates, etc.
>
> For example, today's code:
>
> if (myOracle.canInstall(ius, profile, monitor)) {
> director.install(ius, profile, name, monitor);
> } else {
> // tell user I can't install, not sure why
> }
>
> new code:
>
> DirectorResult result = myDirector.install(ius, profile, name, monitor);
> if (result.getStatus().isOK()) {
> // call some helper
> myHelper.performInstall(profile, result, monitor)
> } else {
> // Now I can hopefully tell the user something interesting
> based on the status
> }
>
> For some reason, I was hoping/expecting DirectorResult to have more
> behavior. I looked at DirectorResult and had no idea what to do with
> the operands. Then I found the sizing example in the director app.
> Creating a sizing phase and performing it in the engine with the
> operands definitely feels a lot different than anything else I've
> had to call. I'm an API client who prefers not to know the inner
> workings of the engine.
>
> So I'm wondering if DirectorResult could be the place where these
> helpers live...
>
> DirectorResult result = myDirector.install(ius, profile, name, monitor);
> if (result.getStatus().isOK()) {
> SizingInfo info = result.getSizeInfo(); // I use SizingInfo
> instead of SizingPhase because it doesn't feel like a phase from the
outside
> // Use this info to tell the user more about the install
> // Once they decide to install
> result.performInstall();
> } else {
> // Use result.getStatus() to explain why the install can't
> be performed
> }
>
> Of course, helper methods located elsewhere could do the same
> thing...pass the helper a DirectorResult and it does the work.
> It's just a matter of whether you view DirectorResult as a data
> structure or as the actual helper.
> Either way, I prefer to treat it as something opaque that I give to
> someone smarter than me to do the work, rather than build the phase
> set and run the engine, etc.
>
> susan
>
>
>
>
> Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 10/03/2007 07:06 AM
> Please respond to Equinox development mailing list
>
>
> To: Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>
> cc:
> Subject: [equinox-dev] [prov] Director API experiments
>
>
>
>
>
> Hi,
>
> Back in August, we had a discussion [1] around changing the director API
> (or having a Oracle) to enable scenarios like:
> - show the user with what will happen as a result of adding / removing an
> IU (e.g. compute the install size, etc.)
> - allow for download of the artifacts before doing configuration
> - decouple the engine from the director
> - ...
>
> Yesterday I finally got to prototype this new API. To avoid disruption, I
> created a new class called IDirector2. This new API no longer calls the
> Engine but instead returns an array of Operands (see these Operands as a
> delta that takes the profile from its current state to what you want it
to
> be). These Operands can then be used as input to the engine to actually
> change the profile, or do some reasoning about them.
>
> In order to excercise this API, I changed the director application and I
> also implemented an install / download size. So far so good. Still one
> things annoys me: If this API replaces the IDirector API then simple
> install scenarios become hard to do programmatically since the engine
needs
> to be called separately. So there are several possibilities:
> - have IDirector and IDirector2 be one
> - have the Oracle have the ability of IDirector2 and keep IDirector as is
> - replace IDirector with IDirector2 and have an higher API to address the
> simple usecases, much like we have the ProvisioningHelpers
>
> What do you think?
>
> PaScaL
>
> [1] http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02717.html
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
