Peter Tröger
2011-04-06 22:22:09 UTC
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.
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.