[DRMAA-WG] IDL issues

[Daniel Gruber]

see inline

Cheers,
Daniel

Am 22.06.2011 um 00:05 schrieb Andre Merzky:

> 2011/6/21 Peter Tröger <peter at 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.

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. 

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.

Like Peter said destroying works on the name not on an existing session.
This could speed up session cleaning in some cases.


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

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

I would be fine with adding drmaaName, where implementors can add 
their vendor/organization name inside. Just for the case if...

> 
> 
>>>   - 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 at ogf.org
>  http://www.ogf.org/mailman/listinfo/drmaa-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20110622/5d7bf21c/attachment-0001.html