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

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

Dave,

----- Dave Wootton <dwootton@xxxxxxxxxx> wrote:
> Al
> The PE and probably LoadLeveler resource managers will fit case 2 as you 
> noted. 
> 
> I don't think I have a reason for a non-partitioned case since I expect 
> each attribute to appear on only one tab of the tab set. However, if there 
> was a case where an attribute could appear on multiple tabs, I would 
> expect that the value that was applied was the value that was set when the 
> apply/run/profile button was clicked and not te value from a hidden tab 
> later in the tab sequence. I'd also expect that if I changed a value in 
> one tab and then switched to a different tab which contained the same 
> attribute, than the value now appearing in the second tab would be 
> identical to the value that was set in the tab I just switched from. I 
> think it would be confusing to me if the same attribute on two tabs had 
> different values.

Good.  I've assured this is the way it works.


> 
> I might have reason to use case 3 to support basic/advanced mode for the 
> PE resource manager. If I was to do that, I think I would have a model 
> where tab 'A' was non-shared and tabs 'B..E' shared. In my case I would 
> expect that if the user had tab A visible when he hit apply/run, then only 
> the values of the attributes from tab A would be used. If the user had one 
> of the tabs B..E visible, then I would expect only the values from tabs 
> B..E to be used. I think that makes the argument in favor of an explicit 
> list of shared tabs for each tab instead of the boolean you currently 
> have.

Great.  I'm working on it now.

> 
> 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.

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
> 
>