I believe the way we phrased it is that introspective languages, such as the Java platform, will use explicit getters and setters. Non-introspective languages, like C, will use the general getter and setter function from the original DRMAA spec. Daniel Roger Brobst wrote:
======== Regarding specifying unsupported attributes ...
The C-lang and current IDL spec have provisions for handling both required and optional DRMAA attributes.
The 3rd type of attribute, DRMS-specific, was intentionally not discussed in the C-lang binding spec because they do not impact the API. From DRMAA's perspective they are simply attributes which are not named with the DRMAA_ prefix.
Since the C-lang binding has the caller provide the attribute name and value, there is no linkage problem if the underlying implementation does not understand the DRMS-specific attribute.
How does the current IDL spec support DRMS-specific attributes, keeping in mind that the end customer should be able to choose the DRMAA implementation leveraged by the ISV software ? Explicit getters/setters for each attribute would seem to be problematic (certainly from a linkage perspective).
======== Regarding the set of supported attributes changing ...
I think the C-lang binding spec should document that the value output by drmaa_get_attribute_names (and drmaa_get_vector_attribute_names) should be valid for the lifetime of the drmaa session.
-Roger
In a previous e-mail, Peter Troeger wrote:
I think you have correctly identified that the error codes specified in the C-lang spec for drmaa_set_attribute() do not adequately describe the situation when an attribute is not supported.
Should it ? I did not locate any text in the spec which indicates that it is an error to specify an unsupported (or unrecognized) attribute. On the other hand, I also did not locate any text which indicates that unsupported attributes will be ignored.
I think you just discovered a new tracker item. :) It should be specified one way or the other. Otherwise, DRMAA applications will not be portable across implementations.
The current IDL spec seems to make a clear description:
"In the job template there is a distinction between mandatory and optional attributes. A language binding implementation MUST provide implementations for all DRMAA attributes, both required and optional. The setter and getter implementations for optional attributes MUST throw UnsupportedAttributeException in languages which support exceptions. In languages which do not support exceptions, the optional attribute setters and getters MUST return some form of error. The service provider implementation SHOULD then override the setters and getters for supported optional attributes with methods that operate normally."
and:
"5.6.26 UnsupportedAttributeException: The given job template attribute is not supported by the current DRMAA implementation."
In sum, it is specified to be an error if you use an unsupported attribute. If we have a new C-binding document, based on the IDL-spec, then everything should be fine !?
(Caching the supported argument list doesn't help if the list can change during the lifetime of the DRMAA application, as is the case with SGE.)
... You bring up an interesting point. Should a job template be aware of such changes in the DRMS? Right now, ours are. I can easily see the point that a mutable job template is a moving target and could drive a developer nuts. On the other hand, a job template may be very long lived. We completely take away the control from the admin if we allow a job template to hold onto an environment that should no longer exist.
Honestly, what makes sense to me at this moment is to specify the list of supported optional attributes as immutable for a given implementation. In cases like ours, where our support of an attribute is dependent on the configuration of the DRMS, we should return something like DRMAA_ERRNO_DENIED_BY_DRM on job submission. Thoughts?
From the viewpoint of an application developer, I have a very bad feeling with this. I would never expect a change of the list of supported optional attributes, especially not during the runtime of my application. If the admin wants to do some reconfiguration, she is reponsible of considering still running applications. If you really think that this a useful feature at all, I would support the DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to make this explicit.
Peter.
-- *************************************************** * Daniel Templeton ERGB01 x60220 * * Staff Engineer, Sun N1 Grid Engine * *************************************************** * "Roads? Where we're going we don't need roads." * * -Dr. Emmett Brown * * Back to the Future (1985) * ***************************************************