Am 22.06.2011 um 09:31 schrieb Daniel Gruber:
see inline
Cheers,
Daniel
Am 22.06.2011 um 00:05 schrieb Andre Merzky:
...
- 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.
Yeah, but you make explicit that only with a valid handle (i.e. with an
previously opened/created session) you are able to close it. The operation
itself works on a (existing) session not on a string.
Exactly.
My question is: In a OO language binding, wouldn't it be more natural
to have this operation part of the Session itself? JobSesssion xy ... = ...
JobSession.close()? Wouldn't the IDL spec now allow this (it should)?
In case of a close("name") it definitely would not be possible.
Close is paired with the others at the same location, since this allows a more natural mapping for C.
OO languages typically have their own destruction methods, which might implicitely act as close operation.
The language binding is free to define that - and we might mention this in the text.
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!
It is a runtime object, IMHO even a singleton.
Sounds reasonable. Is there a reason to open multiple monitoring session ? I don't think so ...
- 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.
It wasn't. I am sure.
Proposal: don't do chaining, it makes error handling a nightmare - for
almost all languages really, but in particular so for exception-less
languages.
I agree, but the Java people love that *so* much. It is a nightmare for the error handling in the application, so if they use it, they have to deal with the consequences.
- 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 ;-)
I would be fine with adding drmaaName, where implementors can add
their vendor/organization name inside. Just for the case if...
Sounds reasonable, I add it to the list.
- 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).
Ok, noted.