[DRMAA-WG] IDL spec - remaining issues

[Daniel Templeton]

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:
>
> https://forge.gridforum.org/sf/go/artf2826
>
Sorry.  We forgot to talk about the tracker.

Daniel