New Issues under Discussion

UPDATE AS OF SEPT. 20, 1996: All these issues have now been resolved (as indicated below), except for the precise nature of support for collective communications. Where appropriate, the Adopter's Guide has been updated to reflect the resolutions.

A. Issues related to the message-passing system

• A.1. How should collective communications be represented?

  This was discussed at several points during the working group, but implementors were not sure that they could detect group operations (e.g., a broadcast as opposed to a series of sends).

  Are we ready to specify this? It would involve determining the "display option" strings preferred by users, and could probably be done fairly quickly with the metausers group. The result could be an optional feature, for those implementations supporting group communications.

  Action needed by group: Decide whether we should add this to the specification.
  Response: We should add this as an optional feature.

• A.2. How can communicators/groups be dealt with?

  This is a separate issue, since it also involves (presumably) the ability to reflect group-id as a filtering device and/or in the process details window.

  Action needed by group: Decide (a) whether we should add this to the specification; and (b) if so, will it be covered by the following items:

  • adding an optional (for those implementations supporting group communications) group list to the filters, presumably after message type to avoid inconveniencing existing implementations;
  • adding an optional (for those implementations supporting group communications) group field to the process-level display, presumably between the type and source/destination fields;
  • adding an optional group field to the message descriptor data type (see Standard Query Formats), presumably as the last field to avoid inconveniencing existing implementations.
  
  Response: See collective communications.

B. Issues related to interface standards

• B.1. Should there be a Help button on each window, as per Motif guidelines?

  Vendors are free to add Help buttons or menus, according to their in-house policies.

  Action needed by group: None, unless someone disagrees.

• B.2. Must the overview display look like a "main window", even when it will be an extension of some other tool?

  Vendors are free to alter the window framework (in particular, the menubar area) to conform to their in-house style.

  Action needed by group: None, unless someone disagrees.

• B.3. In the process-detail window, can separate scrollbars be used for each queue list, rather than a single one for the whole window?

  This might be an important enhancement for all implementations, and should probably be an amendment to the design.

  Action needed by group: Decide whether we should add this to the specification.
  Initial Response: It appears that this issue should be submitted to the metausers for their comments, since it may over-complicate the windows. Metausers will be asked to compare one-scrollbar-for-all vs. one-scrollbar-per-queue vs. button-controlling-number-of-scrollbars.
  Final Response: The metausers were consistent in indicating that just one scrollbar should be used to controll all queues. They also explicitly stated that vendors should not implement this in different ways, but rather that the GUI should be consistent across platforms.

C. Issues that are (perhaps!) vendor-specific

• C.1. Is there a way to deal with times when data from some tasks is not available (e.g., when the underlying debugger is attached to just a subset of the tasks)?

  Since MQM begins by querying for a list of process IDs, presumably the list returned by the debugger would just show the tasks to which it was attached. Only the subset would be known to MQM, using the current structure.

  However, this would not be reported in any way to the user (is that a problem?). Action needed by group: None, unless someone disagrees.

• C.2. Can the displays refer to "tasks" instead of "processes"?

  The format of the ID is a string, specifically to accommodate variation (some vendors might include process and thread, others process group and process ID; some might call them "tasks"). It is expected that the vendors might need to modify the message-area string and the popup windows accordingly.

  Action needed by group: None, unless someone disagrees.

• C.3. Can both "active" (automatic) and "passive" (manual) updating be accommodated in the same implementation?

  There was some discussion on this, although it does not appear to have been included in the Adopter's guide.

  Action needed by group: Decide whether (a) dual mode should be accommodated; and (b) if so, if the appropriate mechanism (toggle button versus option on menu versus some other) should be decided by the meta-users.
  Initial Response: It was suggested that adopters be free to decide which and how many of the modes to support. However, the metausers will be contacted about whether the selection should be controlled by a specified element (menu items, toggle, or radio buttons), or whether that, too, should be left to the discretion of the adopter.
  Final Response: Metausers were unanimous in stating that the mode should be controlled via the Options menu They were somewhat less conclusive about the wording, but the following names for the two modes dominated:

  		update automatically
  		update on-demand
  	

• C.4. Is there a proposed format for a "message details" window?

  Although this was listed as an important enhancement, it was never part of the specification. That means that implementors are free to handle it if and how they choose.

  Action needed by group: Nothing, unless someone disagrees.