[ogsa-hpcp-wg] Application Templates

[Donal K. Fellows]

Steven Newhouse wrote:
> Good point. I think we need something more defined than just an
> application name... hence going down the URI route. The Application
> name would be one place to the defined URI. The version component of
> the URI could then be placed in the JSDL version element. Or an
> ApplicationURI element placed at this level and just the Version
> element used.

I'd like to see application name and version be things that can be tied
through the whole info model. It brings it all together.

> This is one of the discussion points - is an application template
> tied to the application in general, or the system that it is deployed
> on. I feel it's the latter... but then you cannot 'compare' URIs on
> different systems without analyzing the structure..

Exactly. I don't have the answer BTW.

> I feel not. Templates are a property of the system. The whole point
> of going down this route is for users to just say run my Matlab job,
> or my big CFD simulation. Any user specific details (input files)
> should be provided by the user - other details filled in by the
> system.

OK, fair enough. So long as we're clear, we're good.

> Yeah. I'm probably tempted by 'append' and let the application deal
> with conflicts - probably badly!

Dealing with bad input is "Not our problem". :-)

[re Username]
> Disagree - the system manager might want all users to run as a
> particular user but to keep the record as to who submitted the job.

Default or override? Tricky. Might need to allow for both. (Might also
need to extend this idea in other places that have default/override
behaviour. Maybe a new attribute in the template specification?)

>> It would be nice if templates could support named replacement parts.
> 
> Not sure what you mean by this?

I used to work on a project which (ab)used JSDL. What they wanted to do
was to specify some attributes of an execution by name and not by
position (e.g. for a "compress file" application they might have the
name of the file and the compression level as named attributes). They
did this (much to the surprise of the developers of the BES-analog) by
using particular environment variable names and then assuming that the
JSDL consumer (which had its own templating mechanism) would substitute
the environment variables in the right place.

Hopefully I've explained right the scenario.

> I don't see a driving scenario for this at the moment... but if they
> were published yes.

Agreed. If they're not published, there's no need. View it as a
conditional comment. :-)

Donal.