[DRMAA-WG] IDL issues

[Peter Tröger]

I added close() semantics and the singleton model decision to the list of open issues for the next conf call.

Thanks,
Peter.


Am 22.06.2011 um 10:35 schrieb Andre Merzky:

> 2011/6/22 Daniel Gruber <dgruber at univa.com>:
>> 
>>   - 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.
> 
> As the session has the name as property, I think close could (and
> should) very well be a member of the object, without the need for an
> argument.
> 
> 
>> Like Peter said destroying works on the name not on an existing session.
>> This could speed up session cleaning in some cases.
> 
> ok.
> 
> 
>>     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.
> 
> If it is a singleton which is already instantiated (e.g. by loading
> the library), then it is being opened, not created?
> 
> Anyway, I begin to understand the model - much appreciated...  One
> might want to make those things clearer in the spec though, as others
> will likely stumble over similar questions?
> 
> 
> Cheers, Andre.
> 
> 
> -- 
> Nothing is ever easy...