[DRMAA-WG] IDL issues

[Andre Merzky]

2011/6/21 Peter Tröger <peter at troeger.eu>:
> Hi,
>
>> The bigger ones are likely caused by my limited understanding of the
>> background which led to the design, so please bear with me - I don't
>> want to reopen any discussions which have been closed for good...
>
> I like your attitude ;-) ...

;-)

Thanks for the answers, that helps.  Some comments inlined below.

Cheers, Andre.


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