[DRMAA-WG] IDL spec - remaining issues

[Rajic, Hrabri]

>-----Original Message-----
>From: drmaa-wg-bounces at ogf.org [mailto:drmaa-wg-bounces at ogf.org] On Behalf
>Of Rajic, Hrabri
>Sent: Tuesday, October 31, 2006 9:37 AM
>To: Peter Tröger; Daniel Templeton
>Cc: DRMAA Working Group
>Subject: Re: [DRMAA-WG] IDL spec - remaining issues
>
>>
>>>> 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.
>
>

Introspection could be very valuable for GUIs, visual IDE appp builds, or when building DRMAA apps initially (and wanting to know every conceivable facility there - minority set of the users).

Hrabri