Hia folx, I stumbled over a couple of issues in the IDL spec, and would appreciate clarification / feedback. Some are minor, some are major. The bigger ones are likely caused by my limited understanding of the background which led to the design, so please bear with me - I don't want to reopen any discussions which have been closed for good... - the enum ResourceLimitType does not seem to be used anywhere - the enum JobTemplatePlaceholder does not seem to be used anywhere - I think the following is asymmetric. There is likely a reason, but I am not sure I understand it: - job session: create (name, contact), open (name), close (session), destroy (name) - reserv. session: create (name, contact), open (name), close (session), destroy (name) - monit. session: create ( contact), close (session) From the above, it seems like create/close are pairs? I would naively expect the following pairs: open/close and create/destroy, as usual - what is the rationale? Why is the Monitoring session handled differently, i.e. has no name/open/destroy? - jobInfo.exitStatus is a long. Shouldn't that be an int? Or is that an IDL artifact? - inErrorState: this is not explained - what does it mean? Am I getting reservation in an error state? What for? also, reservations don't seem to have state, really? (BTW: I did not check if all attributes are explained, just stumbled over this one. This should be checked). - JobWaitStarted/Terminated: The function returns always a Job object, in order to allow chaining, e.g. job.wait(JobStatus.RUNNING).hold(). The session-level functions I find that strange and inconsistent - chaining is not supported elsewhere AFAICS, why here? What is the advantage over 'job.wait(JobStatus.RUNNING); job.hold();'? this has exactly the same race conditions... - StringList getJobSessions(); StringList getReservationSessions(); All getXYZ methods in the API return XYZ, apart from these two - which return the name of XYZ. IMHO, they should either return XYZ, or should be called StringList listJobSessions(); StringList listReservationSessions(); - sessionManager.drmaaVersion: this seems to return the implementation version, not the DRMAA spec version (i.e. 2.0). I think this is useless without also reporting the drmaaName, i.e. the implementation name. Otherwise the user may report to you that she is using version 4.5, but what implementation?? ;-) - what is the use of the sessionManager interface? It cannot be created/destroyed, so is likely a singleton? This however is not explicit in the spec. A sessionManager does not seem to have state (apart from the new addition of a monitoring callback), but a stateless singleton is rather useless? All methods can easily be provided as free functions - is a language binding allowed to do that? - "sessionName: is supposed to be unique - if a session with that name was created before, an exception is thrown." Hmm, 'created before'? ever? by anybody? Or only for this session manager instance? Or this DRM system? etc etc. Cheers, Andre. -- Nothing is ever easy...