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