Re: [equinox-dev] [prov] Ruminations on IDirector vs. ProvisioningHelper

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Perhaps we should agree on some workflows/user
types that can drive this discussion.

-  Simple: For simple users/flows
there are not that many choices.  They say they want to use Foo and
the Director and friends determine if all prereqs are available.  Either
they are or they are not.  If the request is possible, they'd probably
like to know if it is time to: a) take a bite of a donut, b) go get some
coffee, c) have a bio break with that, d) head out for lunch or e) go home.
  If the request is not possible, it can be suggested that the user
go off and find another repo that knows about the missing bits but beyond
that they are SOL.  We have searched the known universe and come up
empty handed.  There is also a conflict case where installing Foo
is possible but only if Bar is changed/removed.  This gets a bit advanced
for these users.  A very carefully worded simple question needs to
be asked (e.g., "How much do you want to use Foo?  Rank on a
scale from life threatening to I thought it might be interesting")

- Moderate: In more advanced cases users
say they want to use Foo and are happy to have the system figure stuff
out but once things are ready to go, they want to snoop and have veto power.
 They want to know "why".  These are the "backseat
Directors" or, for those of you with kids, "Four-year-old Directors".
 These are dangerous people.  They want to know everything but
at the same time, don't want to have to know everything.  They are
pissed off by known unknowns and when they do know something they want
to be able to change it.

- Advanced:  Like the moderate
users, advanced users are curious and somewhat controlling.  The difference
is that they are more receptive to button clicks and work.  They really
do want to see exactly why version X was choosen to when they know repo
Y is so much more cool, why artifact A is coming from repo W, ....  These
people are like driving instructors.  They are there with you in the
car and have a duplicate set of controls and that funky rear-view mirror.
 They can take over at the drop of a hat.

- Extreme:  Then there are the
extreme power users.  For them, no amount of control is too much.
 They want to BE the Director and Engine.  We should just open
an XML editor and let them craft the messages that are sent back and forth
;-)  

So what does this all have to do with
the current discussion.  Well, IMHO the M2 user should be Simple.
 They need a bit of feedback on what's going on but for the most part
no news is good news.  Computing the size/time requirements seem like
the most pressing matter.  I wonder if this is something we can do
with a sort of "dry run" where the director and engine do their
thing to figure out exactly what "would" happen but stop short
of actually doing it.  The UI can then interrogate the results to
see how much download there was, time that would have been needed, ...
and report that to the user.

This is not to say that the planning
object discussed is not needed but rather the information it provides is
more useful in the moderate to advanced usecases.  Other scenarios
that will need this kind of function are editing (validation, checking,
...), sys admin operations (simulate, validate designs/jobs) etc.  I
agree with Tim that we should look to separate out the building blocks
needed to implement these functions.  

Jeff

p.s., not sure quite how useful any
of this was but it was kinda fun to write...

"Tim Webb" <tim@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/14/2007 09:00 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] [prov] Ruminations on IDirector vs.        ProvisioningHelper-like entity

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