[DRMAA-WG] IDL spec - remaining issues

[Peter Tröger]

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

Something for today ...

Peter.