Hi, here are my comments, we can clarify the remaining issues in todays phone conference ...
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.
In general, I expect the IDL spec to be more generic than the language bindings. It is good to describe SPI-related issues for particular languages, but the approaches might differ between .NET, Java, Python or something else. Therefore, I would wipe out all SPI comments in the IDL spec, and leave the according sectioning to the language-binding author.
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?
Initially, I thought it would be possible to avoid some of the boolean properties by introducing 'non-value' as possible result for things like exit status and term signal. But at the end, the resulting code looks the same. But my first question is still valid.
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.
All mandatory and optional DRMAA parameters are part of the JobTemplate interface, and therefore available in every implementation. This does not hold for implementation-defined parameters (e.g. "condorUniverse"). The IDL spec does not have getAttribute() and setAttribute() any longer, so how should I set an implementation-specific parameter without breaking interoperability of my code ? In C, I could determine the DRM identity and use an according attribute name in drmaa_set_attribute(): if (!strcmp(drm, "Condor")) drmaa_set_attribute("condorUniverse", "mpi"); In IDL, I could use the according setter method of the JobTemplate implementation, but this would break portability of the code to another DRMAA implementation: JobTemplate jt = session.createJobTemplate(); ((JobTemplateImpl)jt).setCondorUniverse("mpi"); Otherwise, I need to use introspection to find the according getter function dynamically during runtime. This is what we currently suggest in the spec. Is this really the way we want people to code ? There might be better solutions.
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.
Majority decisions are fine ;-) ...
We have also an open tracker specifically for the IDL spec:
Sorry. We forgot to talk about the tracker.
Something for today ... Peter.