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.