[DRMAA-WG] IDL issues

[Andre Merzky]

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...