Re: [ptp-dev] use case question regarding JAXB launch tab configuration

["Albert L. Rossi" <arossi@xxxxxxxxxxxxx>]

> > 
> > However, I am thinking I prefer to implement advanced/basic mode as two 
> > separate resource managers to make the user's choice a little more 
> > explicit than relying on what tab is currently visible when the user hits 
> > apply/run to make the decision which mode to run. Particularly since I'm 
> > concerned that the user may not remember whether the run configuration was 
> > last used in basic or advanced mode when he hits the 'run' icon to run the 
> > last selected run configuration instead of hitting 'run configurations' 
> > and making an explicit choice. So with my current thinking, I probably 
> > wouldn't use case 3.
> 

This is where having a script is advantageous.  The user can click "view script" to make sure the values are what she expects.  I suppose eventually we could add something similar for "inspect launch command".

Al

> OK.  But I agree that the option, if it exists, should be based on an explicit superset.  
> 
> If Greg gives me the go ahead with the XSD/Java binding change for this one class API, the internal changes are all in place.  I've made the changes locally and am getting ready to test it.
> 
> Thanks for the feedback,
> 
> Al
> 
> > Dave
> > 
> > 
> > 
> > From:   "Albert L. Rossi" <arossi@xxxxxxxxxxxxx>
> > To:     Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> > Date:   05/23/2011 11:38 AM
> > Subject:        [ptp-dev] use case question regarding JAXB launch tab 
> > configuration
> > Sent by:        ptp-dev-bounces@xxxxxxxxxxx
> > 
> > 
> > 
> > I have been reviewing the "shared/not shared" switch on the launch tabs, 
> > and have a question about the resulting configuration.
> > 
> > To remind you what this is all about.  Say we define three separate 
> > top-level controllers for a given RM.  Call them A, B, C.  Now, let's also 
> > say that T, the complete set of attributes, is defined as {t0, t1, t2, t3, 
> > t4, t5, t6}. 
> > 
> > Case 1:  shared = false for all three.
> > 
> > This means that these are independent subsets in terms of what goes into 
> > the Launch Configuration.  For instance, let's say that:
> > 
> > A = {t0, t1, t2}
> > B = {t0, t1, t3, t5}
> > C = {t0, t1, t2, t3, t4, t5, t6}
> > 
> > If the use is working with A, and does Apply or views the script or 
> > chooses Run, the Launch Configuration will only have values t0, t1, t2 
> > defined.  If the user launches from tab C, the Launch Configuration will 
> > have all of them, etc.  Note, however, that since the three tabs represent 
> > different subsets of T, the values of t0, t1, etc. are nonetheless shared 
> > between A, B, and C, so that if the user sets t0 in C and then flips over 
> > to A, any previous value for t0 set through A will have been overwritten 
> > and the user will see the new value for t0 there as well.
> > 
> > Case 2:  shared = true for all three.
> > 
> > This means that no matter which tab the use hits Apply or Run from, the 
> > entire set of values for T are written to the Launch Configuration.  This 
> > use case makes most sense when you have partitioned T among the tabs, 
> > e.g.,
> > 
> > A = {t0, t1, t2}
> > B = {t3, t4}
> > C = {t5, t6}
> > 
> > but will still pertain if there are intersecting values.  This leads me to 
> > my first question.  Does Case 2 ever make sense in a non-partitioned case? 
> >  If so, then I believe I need to fix one thing:  currently, if there is a 
> > value set in more than one shared environment tab, it is not necessarily 
> > the visible value which gets saved, but the value on the last tab (C in 
> > this case), because the parent updates the tabs in order.  In order to 
> > make this intuitive, I would need to change this update to do the rotation 
> > modulo the number of tabs beginning with the tab just after the visible 
> > one and ending with the visible tab.
> > 
> > Case 3:  A & B shared, but C not shared (or some combination of on/off). 
> > This doesn't work quite as one would expect.  If the user clicks Apply or 
> > Run from A or B, the Launch Configuration gets the values on A,B _and_ C, 
> > but if the user is working from C, the Launch Configuration gets only the 
> > values in C.  While this makes sense from one standpoint, it may not be 
> > intuitive to the user, who probably thinks that A and B should not include 
> > the values in C which are not in the intersection of A,B, and C.
> > 
> > All of this may seem like a silly set-theoretical game, but the two basic 
> > scenarios were meant to support cases which already exist:
> > 
> > 1 = an RM like PBS, where we wish to present the user with a set of tabs 
> > moving from basic to more inclusive.
> > 2 = an RM like OpenMPI or PE (?), where the tabs represent categories of 
> > attributes.
> > 
> > I guess my question is:  should I go ahead an make the two changes I have 
> > suggested here? That is, ensure that the values on the visible table 
> > overwrite any other tab values, and fix the way that the shared/not shared 
> > flag works so that it works as in Case 3 (a little more complicated)?
> > 
> > One last thing:  I have fixed a little bug that existed in the restoration 
> > of default values.  This button now applies _only_ to the current tab, 
> > regardless of whether the tab's shared property is true or false.
> > 
> > Al
> > _______________________________________________
> > ptp-dev mailing list
> > ptp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ptp-dev
> > 
> > 
>