[DRMAA-WG] IDL issues

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