Andre Merzky
2011-06-21 20:39:12 UTC
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.
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...
Nothing is ever easy...