Sounds good. So if we can have an Oracle that returns a ProvisioningDeltaDescription or whatnot that describes the various actions that would be performed. By having this as another object, we can provide additional services to help describe in a human-readable format the operation as well as in machine-understable styles to allow serialization. What would the input to such a function be? Would you still use a full Profile or would you use a ProfileDescription object that can be accessed off of a Profile? Having it as a separate object may also again further user-understandable descriptions of the interface.
Tim On 8/14/07, Pascal Rapicault <[EMAIL PROTECTED]> wrote: > > If only we could have a console as a UI... I'm really amazed by the > requirements the UI put ;-) > I agree that it is interesting / mandatory to be able to show disk space > and things like that, however ProvisioningOperand is wrong thing to base a > UI on since it contains the information to drive an engine and this will > likely be more detailed than what we have now (Simon is working on a new > API for the engine). > > As for the code code, the oracle I have in mind will share code with the > director to ensure consistency. > > > > > "Tim Webb" > <[EMAIL PROTECTED]> > Sent by: To > equinox-dev-bounc "Equinox development mailing list" > [EMAIL PROTECTED] <[email protected]> > cc > > 08/14/2007 05:32 Subject > PM Re: [equinox-dev] [prov] > Ruminations on IDirector vs. > ProvisioningHelper-like entity > Please respond to > Equinox > development > mailing list > <[EMAIL PROTECTED] > pse.org> > > > > > > > Pascal, > > I could see a benefit to knowing the full set of operations since some > users don't want their system changed without understanding the impact. > More importantly, it is interesting to be able to show users information > such as the amount of data that will be downloaded as a result of X, being > able to calculate needed disk space before performing the operation, and > letting the user know that selecting that one little feature caused 200mb > of extra stuff to be included. > > The issue I see is that a lot of the interesting information ends up > following many of the same paths that are currently used in the Director. > Instead of duplicating that code into another object called an Oracle, > might it make sense to pull some of that logic out of the Director into a > shared object? Whether it's called an Oracle or not, I think there should > be one set of code that determines the set of operations to be performed, > and I don't believe that we need to duplicate that logic. > > Thoughts? > Tim > > On 8/14/07, Pascal Rapicault <[EMAIL PROTECTED] > wrote: > Susan, > > It seems to me that what you are after if some kind of "oracle" who > given > a > profile, a bunch of IUs selected by the user, and repos would be able to > tell which IU can be added to the profile. > Unfortunately the "oracle" is not implemented. but something could > probably > be done quickly based on the code available in the director. > > Also would you want to show to the end user what will happen? > > PaScaL > > > > > > Susan M Franklin > <[EMAIL PROTECTED] > s.ibm.com > > To > Sent by: Equinox development mailing list > equinox-dev-bounc < [email protected]> > [EMAIL PROTECTED] > cc > > > Subject > 08/14/2007 03:46 Re: [equinox-dev] [prov] > PM Ruminations on IDirector vs. > ProvisioningHelper-like entity > > Please respond to > Equinox > development > mailing list > <[EMAIL PROTECTED] > pse.org> > > > > > > > > Tim, > I have the same concerns/questions as you pose here, you are just a day > or > so ahead of me....I am beginning to work on the UI that follows more of > an > update manager workflow in Eclipse. The admin UI in M1 forced you to > locate the IU you wanted and then select a profile. The more typical > use > case, where you are looking to install/update from your profile, is my > next > task. I've had the same low level concern (but had not yet investigated > the code thoroughly) that you have to ask the code to do something > before > you can know what will be done. I was wondering if the fact that you > get > pre and post notification events was going to help me, but I don't think > it > will. > > So I'm hoping Pascal or someone can elaborate on this issue, as I'm > about > to face it myself and will have more to contribute to this conversation > in > a day or so.... > > >Currently the IDirector interface has two methods : install and > uninstall. > In looking through the code of ProvisioningHelper and IDirector > (SimpleDirector) I'm not sure as to the right way to >describe to the > user > the series of operations that would be performed in installing software > X > > prior to actually initiating the installation. I could duplicate > similar > code to what is found in >SimpleDirector using the > ProfileInstallRegistry > and DependencyExpander to determine what would be required > > susan_______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev >
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
