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

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

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