2011/6/21 Peter Tröger <peter@troeger.eu>:

Hi,

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

I don't get your point. Creation returns a new persistent XXXsession

instance. Open allows you to re-access the persistent existing session.

Close is for cleanup after both create and open. Destroy throws away the

persistent information, and therefore does not demand an open session

instance.

Why not close(name), so that all ops work with name as arg?  Would be
more symmetric.

    Why is the Monitoring session handled differently, i.e. has no

name/open/destroy?

Monitoring session have no persistency, so they need no name for opening,

and no destruction.

If something has a create, I would expect it to have a destroy, too.
That might just be me, but semantically those two go together...

Anyway, your explanation helps!

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

Chaining was raised as important thing only for the wait functions. I am too

lazy to search the minutes for this, but it is handy in OO languages. We

didn't spend deeper thoughts on supporting this elsewhere.

You may want to make sure that chaining was *not* introduced to
prevent race conditions - because it does not.

Proposals welcome.

Proposal: don't do chaining, it makes error handling a nightmare - for
almost all languages really, but in particular so for exception-less
languages.

  - 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?? ;-)

You get the DRMS type, this is your DRMAA implementation. I propose that

there will be no two DRMAA implementations for the same DRM system in the

same language.

Woah - you MAY be able to ensure that for the current WG constituency,
but you are writing a *standard*!  You expect there will only *one*
implementation using fork, for example?  Only one implementation for
PBS?  You can never ensure this, and that contradicts the idea of an
standard, really...

The potentially missing API call is a minor point really, but your
argument does not hold water ;-)

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

Yes, it's a singleton.

This should be noted in the spec (unless I missed it).

Yes, you can do free functions in the language

binding. IDL does not support that.

Ok, thanks.


Cheers, Andre.


--
Nothing is ever easy...
--
 drmaa-wg mailing list
 drmaa-wg@ogf.org
 http://www.ogf.org/mailman/listinfo/drmaa-wg