Re: [ptp-dev] resource_manager.xsd version 5 questions/comments

[Dave Wootton <dwootton@xxxxxxxxxx>]

Al
For argslist handling, what I was thinking
is that a run configuration may contain settings for attributes which are
not valid for the currently selected resource manager configuration, probably
because that same run configuration was used with a different resource
manager. Because of that, the processing that builds the run command needs
to be sure that any attribute with a value stored in the run configuration
is included in the run command only if that attribute is valid for that
resource manager's configuration.

I think what values get put in the run
configuration dialog is already handled by your approach since the XML
file is what defines what attributes appear in the run configuration dialog.
If your processing is such that only attributes that appear in the run
configuration dialog get built into the run command, then that should do
what I'm suggesting. If other attributes previously stored in the run configuration
are also included in the run command, then those need to be filtered out
since they may not be valid and could cause the run to be rejected.

Your approach to an advanced mode command
script is fine with me as well as adding enumerations for specific browse
buttons.
Dave

From:	"Albert L. Rossi" <arossi@xxxxxxxxxxxxx>
To:	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
Date:	01/26/2011 05:10 PM
Subject:	Re: [ptp-dev] resource_manager.xsd version 5 questions/comments
Sent by:	ptp-dev-bounces@xxxxxxxxxxx

---

Dave, 

1)  I'm not quite sure how you're thinking this should work.  It
seems to me that there should indeed be an attribute on the job-attribute
marking it for OS.  The RM implementation needs to be agnostic as
to what it really is (LL, PE, etc.).  If there is a general filtering
mechanism, this can be implemented, I think, without too much difficulty.
 For dynamic attributes, I just assumed that whatever command you
configure to get them will give you the correct ones.

2)  This is one-size-fits all.  It's basically saying to the
user:  here's an editor; take a customized script you've written,
or write one, and that's what we'll give to the launch command.  What
you see is what you get.

3)  I see no problem adding one or more enumeration types that correspond
to those variants.  This widget I envisaged as being a double widget:
 a text box followed by a push button.  But the dialog that comes
up could be different based on the subtype.

Thanks, Al

----- Dave Wootton <dwootton@xxxxxxxxxx> wrote:
> Al
> I took a look at version 5 of your schema and I think it generally
does 
> what I need. Once there is a workable implementation I'll have to
> experiment a bit. I do have a few comments/questions
> 
> 1) I was looking at the definition of the argslist element and the
> reference to dynamic attributes. I'm not quite sure hos this is supposed
> to work, but what occurred to me at this point was that I have a run
> configuration that has a set of attributes with values stored in it,
where 
> I may have used that same run configuration with several different
> resource managers that accept only a subset of the attributes that
are in 
> the run configuration. For instance I may use the same run configuration
> to run PE applications on both AIX and Linux, where some PE options
may 
> not be valid on Linux or AIX. Do you anticipate that the resource
manager 
> will filter the attributes in a run configuration so that only the
set of 
> valid attributes and their values is displayed in the run configuration
> and passed to the application in the run command? I'm thinking the
set of 
> allowable attributes that would be displayed and passed to the application
> would be what's defined in the XML file for that configuration and
the 
> rest of the attributes in the run configuration would be ignored.
> 
> 2) In the launch-tab element there's an advancedModeEnabled element
that 
> allows the user to edit/create a script file. What's expected to be
in 
> that script file and how does that get passed in the run command.
Is this 
> expected to be the exact command(s) used to invoke the application
or is 
> it something like a .rc file with a bunch of environment variable
> settings? I think a script with the exact commands would be acceptable
> since this is 'advanced mode', but not sure that's what you intended.
> 
> 3) I was looking at the widget element. In there, there is an enumeration
> for browseButton. In my PE implementation, I have three different
> variations of a selector dialog, browse for an existing directory,
where 
> only directories can be selected. browse for existing file which accepts
> only file selections and browse for file where the user may type in
the 
> name of a new file once he navigates to the desired directory. Do
we want 
> that level of specification in the schema?
> 
> Dave
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev