[DRMAA-WG] IDL issues

[Peter Tröger]

See inline.

Best,
Peter.


Am 22.06.2011 um 09:31 schrieb 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. 

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.

>> 
>> 
>>> 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/86c107b4/attachment.html