IDL spec - remaining issues
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. 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 ? 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 ? 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. 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. We have also an open tracker specifically for the IDL spec: https://forge.gridforum.org/sf/go/artf2826 Peter.
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
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.
Peter, Comments inline. Peter Tröger wrote:
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.
I can agree with that. The SPI section in the Java binding currently just says that an implementer has to provide implementations for the abstract classes and may extend the non-abstract classes. All of the classes, however, are specific to the Java binding. The DRMAA-defined types are now all interfaces.
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.
We talked about the first question, but I don't remember what we said. I remember that Hrabri pointed out that the IDL binding has already introduced some new exceptions, so one more wouldn't be earth shattering. We should bring this up again today, though.
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.
I don't know how other introspective languages work, but Java uses late binding. That means that if I take your code above and run it using the SGE binding, it won't fail until it hits that line of code. That means that if I wrap it in a test for the DRM type, the code will work with all DRMAA bindings, just like in the C example. I only see introspection as an option for cases where you don't know what properties are available, but you want to see what they are anyway, such as in a property sheet. Daniel
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.
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (3)
-
Daniel Templeton -
Peter Troeger -
Peter Tröger