[DRMAA-WG] IDL spec - remaining issues

[Rajic, Hrabri]

>
>>> 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.
>

If the users use underlining DRMS functionality then they know exactly what functionality they want to access.  There is no way avoiding if-then-else logic in the code, making it looking non-portable but executing correctly on all the implementations.
Using introspection to avoid explicitly mentioning all the version number of the same implementation family (e.g. Condor) might be more preferable.  Using DRMAA implementations to hide volatility of unstable DRMS interfaces could be another approach.  It goes w/o saying this is better left to the implementers to manage. 

Regards
	Hrabri