Peter, we didn't manage to cover all the points below in the last meeting because I wasn't sure what you wanted to say about them. More info in-line. Daniel Peter Troeger wrote:
Dear all,
Dan and me finished the work on the latest IDL specification v0.38. It is in sync with the pre-final Java spec v0.7 provided by Dan several days ago.
The following issues are left open, and should be clarified by the group:
Sections 3.1 / 4.2 / 5 / 6 / 6.2:
Currently, the IDL spec borrows the notion of a service-provider interface (SPI) from Java world. We are not sure if and how this concept really fits to a language-independent, interface-oriented description. We could also describe the intended distinction only informally, without further influence on the document and interface layout. We decided that you and I need to revisit this topic based on the changes to the 0.7 Java language binding spec's SPI section.
Section 6.1:
Which exception should be thrown when non-available job status information is queried (call of 'exitStatus' with 'exited=false')?
In general, do we really want to keep the POSIX-derived semantics for the JobInfo interface ? Predictably, the majority answer was that POSIX is good. Did you have an argument you wanted to make for why we should drop the POSIX semantics? Section 6.2:
setAttribute() and getAttribute() are not needed in the IDL-based specification of a JobTemplate interface. However, the reading and writing of implementation-specific job template attributes then demands introspection capabilities, in order to find the getter and setter functions. Is this acceptable ? Sorry. I wasn't sure what you meant with this one.
Section 6.2.14 / 6.2.15:
Dan and Peter disagree if DRMAA 1.0 allows output and error parameters in a job template to be a directory name, instead of a file name. Peter, you were correct. The output and error stream attributes should be files.
Section 6.3.14:
The IDL spec adopted the usage of comma-delimited string lists in some parameters. We might want to switch to a list types instead. Roger and I were for keeping the comma-delimited string. Andreas didn't really care. Hrabri was opposed, but conceded. The argument was that the comma-delimited string optimizes for the common case, that being calls made after drmaa_init(), whereas the list representation optimizes for the uncommon case, calls being made before drmaa_init(). Andreas' point was that the list representation is a cleaner, more IDL-like description. In the end, we decided that adding a step to the common case was less bad than added two steps to the uncommon case.
We have also an open tracker specifically for the IDL spec:
Sorry. We forgot to talk about the tracker. Daniel