-----Original Message----- From: drmaa-wg-bounces@ogf.org [mailto:drmaa-wg-bounces@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