Conference call - November 23th - 19:00 UTC
Dear all, since the public comment period for DRMAAv2 is now over, we need to discuss our reaction on the comments. The next DRMAA conf call is therefore scheduled for December 7th, 19:00 UTC. We meet on Skype, please find me under the nickname "potsdam_pit". Preliminary meeting agenda: 1. Meeting secretary for this meeting? 2. Remaining public comments on DRMAAv2 (http://ogf.org/gf/docs/comment.php?id=377) 3. Next steps with the C-binding Best regards, Peter.
Corrected the subject line, sorry for the confusion. Best regards, Peter. Am 05.12.11 17:31, schrieb Peter Tröger:
Dear all,
since the public comment period for DRMAAv2 is now over, we need to discuss our reaction on the comments. The next DRMAA conf call is therefore scheduled for December 7th, 19:00 UTC.
We meet on Skype, please find me under the nickname "potsdam_pit".
Preliminary meeting agenda:
1. Meeting secretary for this meeting? 2. Remaining public comments on DRMAAv2 (http://ogf.org/gf/docs/comment.php?id=377) 3. Next steps with the C-binding
Best regards, Peter.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Participants: Roger, Mariusz, Peter
1. Meeting secretary for this meeting?
Peter
2. Remaining public comments on DRMAAv2 (http://ogf.org/gf/docs/comment.php?id=377)
- scalar attribute question - demands copying of strings, implement via const char* - native types question - decision has to be done by language binding - slots question - slots count should be numeric, is a typo - SessionManagementException question - left over, remove from IDL - exception raise clause question - sad fact, but the group cannot deliver a reasonable list now - will come with existing implementations at grid recommendation phase - DRMAA_JOBID_VAR - makes sense, add it
3. Next steps with the C-binding
Several comments from Roger's in-depth analysis of the last published version of the header file, all agreed by the participants: - make DRMAA2_OTHER_OS and DRMAA2_OTHER_CPU the first items in the enumeration, for better extensibility in later versions of the spec - add more specific comment for drmaa2_list_remove: " "removes the most recent item returned" - whenever parameter is not changed inside the function, make it "const" (e.g. run_job) - non-error output for functions looks counter-intuitive - could be assumed that all these functions never fail - needs check with Andre about initial idea - no obvious code size reduction for DRMAA user - maybe consistency is better Best regards, Peter.
participants (1)
-
Peter Tröger