[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] Director API experiments


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