[DRMAA-WG] DRMAA Extensibility Approach - The Final Fight

[Peter Tröger]

Dear all,

during the phone conference today, we ended up in some discussion about implementation-specific attributes for the Queue struct. In the after-chat with Mariusz and Daniel, it turned out that the problem goes much deeper. In fact, we never finished the (already endless) discussion on how to support implementation-specific extensions of the DRMAA API structs.

In the old times of DRMAA1, we had getter / setter functions. With the (still very feasible) decision for struct-based API design, two extensibility approaches are in use now:

A.) The "free dictionary" approach

- Example: JobTemplate::drmsSpecific
- The struct gets a dictionary attribute for implementation-specific key / value pairs
- This demands an explicit introspection facility for the portal case ("JobTemplate::attributeNames")
- It decouples the DRMAA library implementation from the DRM system implementation, since new DRM features are still accessible with older DRMAA libraries
- The extensibility approach looks the same in all languages, "first-class" citizen of DRMAA API

B.) The "struct extension" approach

- Example: JobInfo
- The language binding finds the most natural way to represent extended structs, and to support "down-casting"
- The language binding can add explicit introspection support only if it is needed
- Implementations offer a specialized version of the DRMAA data struct which is is still usable in a portable fashion
- DRM specific-stuff becomes a direct part of the DRMAA API representation for a particular system

Similar to JSDL and it's "xs:any", it would be good to have only one of these approaches in use.

What's your opinion ?

Best regards,
Peter.