Hi,
2. JobStates -> Merging suspended state to one state and have optional sub-states like for hold state
Changes applied to Wiki document.
4. Thread safety: Taking out the deleteJobTemplate() (implementation will delete it automatically, something like garbage collection when not referenced anymore)?
We had that discussion 4 years ago, see for example here: http://www.ogf.org/pipermail/drmaa-wg/2006-June/thread.html Personally, I would love to throw away all create..() and delete..() functions for data structures. Until now we left them in, because finalizers are no good replacement if you need predictable cleanup code in the library. Meanwhile, the question is if any DRMAA C implementation actually has such code. For Condor, the answer is no, "create_job_template" and "destroy_job_template" are only used for the bookkeeping: http://condor-ext.cvs.sourceforge.net/viewvc/condor-ext/condor_src/drmaa/aux... What about SGE and GridWay ? Do you guys have any relevant logic in "create_job_template" and "destroy_job_template" ?? The second argument in the past was explicit resource management for the application itself. This does not hold for anything but C. In sum: I can live with having these functions only as optional addition in the C language binding, similar to the attribute setter and getter functions. This would mean that they are no mandatory part of the IDL spec.
5. Move JobInfo into Job template. Roger, Dan, Daniel agreed in not to merge. (One reason was: Job object is alive and JobInfo information is static)
'Static' somehow implies that JobInfo is only available in some terminal job state. This was the case in DRMAAv1, but now, we wanted to support also monitoring of running jobs. In this case, JobInfo also becomes alive.
Explicit statement for DRMS that don't have information from master. Up to the implementation which fields are reported.
I don't really understand this part. Thanks, Peter.