[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper-like entity

Tim, since you seem to have a good idea of what you want, could you work on
an API and an implementation (even basic)?

What is a profile description? Is it a profile in which some "things" are
not strictly bound (e.g os is not unbound)?


                                                                           
             "Tim Webb"                                                    
             <tim@xxxxxxxxxx>                                              
             Sent by:                                                   To 
             equinox-dev-bounc         "Equinox development mailing list"  
             es@xxxxxxxxxxx            <equinox-dev@xxxxxxxxxxx>           
                                                                        cc 
                                                                           
             08/14/2007 09:00                                      Subject 
             PM                        Re: [equinox-dev] [prov]            
                                       Ruminations on IDirector vs.        
                                       ProvisioningHelper-like entity      
             Please respond to                                             
                  Equinox                                                  
                development                                                
               mailing list                                                
             <equinox-dev@ecli                                             
                 pse.org>                                                  
                                                                           
                                                                           




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 <Pascal_Rapicault@xxxxxxxxxx> 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"
               <tim@xxxxxxxxxx>
               Sent by:
  To
               equinox-dev-bounc         "Equinox development mailing list"
               es@xxxxxxxxxxx            <equinox-dev@xxxxxxxxxxx >

  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
               <equinox-dev@ecli
                   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 <Pascal_Rapicault@xxxxxxxxxx > 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
                 < susan_franklin@u
                 s.ibm.com >
    To
                 Sent by:                  Equinox development mailing list
                 equinox-dev-bounc         < equinox-dev@xxxxxxxxxxx>
                 es@xxxxxxxxxxx
    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
                 < equinox-dev@ecli
                     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
    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


  _______________________________________________
  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