[DRMAA-WG] IDL spec - remaining issues

[Daniel Templeton]

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:
>>>
>>> https://forge.gridforum.org/sf/go/artf2826
>>>
>>>       
>> Sorry.  We forgot to talk about the tracker.
>>     
>
> Something for today ...
>
> Peter.
>
>
> --
>   drmaa-wg mailing list
>   drmaa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/drmaa-wg
>