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.