[DRMAA-WG] DRMAA v2

[Peter Tröger]

> A few proposals for the meeting today:
>
> PT12:
> < A language binding SHOULD specify numeric values for all DRMAA error
> constants.
> ---
>> Such a language binding SHOULD specify numeric values for all DRMAA
> error constants.

I just changed it as proposed, since he whole paragraph is then clear  
enough.

> PT13:
> I definitely agree that PartialTimestamp is a boondoggle.  I'm not  
> sure
> I agree with using ISO8601, though, mostly because it presupposes a
> date/time *string*.  In a high order language, I want to be able to  
> use
> the native date/time object.

Added as comment.

>  How about specifying that a language
> should use a date/time object or primitive is it has one, and an  
> ISO8601
> string if it doesn't?

To be discussed separately, depends a little bit on the set of  
languages we want to consider.

> PT20:
> I think we can handle the resource request pretty easily, and I  
> think we
> need it.  We just need to add a resourceRequest attribute of type
> Dictionary and treat any such resource request as a hard request.
> Alternatively, we could have a hardResourceRequest and a
> softResourceRequest.  The former is simpler, but the later saves us  
> from
> talking about this again for DRMAAv3. :)

To be discussed separately, added to the draft comments.

> Thinking about whether a resource request should be an optional
> attribute makes created in me a doubt about the value of the
> UnsupportedAttributeException.  Should it be possible to have the
> implementation just ignore unsupported optional attributes?  It would
> certainly be easier than repeatedly attempting to submit until all the
> offending attributes are removed from the template.  Maybe it would  
> help
> to have the exception detail *all* unsupported attributes at once.   
> Just
> thinking out loud here...

I think DRMAA works different, even now. You are expected to retrieve  
the set of supported attributes from the DRM ("attributeNames") before  
you fill out the job template. Your "trial-and-error" should therefore  
never be needed. And we will not re-start the introspection discussion  
here ;-) ...

/Peter.