[SAGA-RG] Context and Session thoughts

[Ceriel Jacobs]

Steve Fisher wrote:
> Hi,
> 
> I am not very clear from the spec how to handle contexts - and it
> would appear that C++ and Java implementations have interpreted it
> differently.

Could you elaborate on that? What is the difference?

> I will try to explain what I think should happen then you
> can all tell me why I am wrong.
> 
> If I have omitted the session parameter to get a default session then
> I get a session with the default context.

... possibly default contextS.

> An implementation (which may or may be adapter based) has a set of
> contexts that it knows about - each with an implementation-defined
> type.
> 
> An  implementation-defined context type in turn defines a set of
> context attribute names that are meaningful to that type
> 
> The implementation defines one of the contexts types that it knows
> about as a default type - so the default context is actually a context
> with the default type.

I don't think there is a single default context type. The default session
may contain various contexts, or none at all. It may initially contain
various default contexts, or none at all.

> If the default context needs to be modified by the user to be useful -
> e.g. storing a password - then there is no benefit in using the
> default context. So the default context should not be modifiable by
> the user. It may be implemented as  a singleton.

I agree that default contexts should not be modifyable, and unfortunately,
there is a way for the user to get at them: session.list_contexts(), which
does not specify that copies are returned. Fortunately, session.add_context()
specifies that a deep copy of the specified context is added to the session,
so a session always contains copies. And if the default session contains
default contexts, it should actually contain copies of them.
In hindsight, it might have been better to make contexts within sessions
unmodifyable, by having list_contexts return copies.

> The user can also create a context with a type known to him and to the
> implementation. He may need to set attributes of this context before
> it can be used. The implementation must not modify any attributes -
> though the constructor may set attributes to sensible defaults which
> can then be modified by the user.
> 
> The set_defaults call should *not* be in the spec - it is purely an
> implementation thing.

I think I agree with that. It is a pity that the Context
constructor has a default value "" for the context type.
IMHO, the Type attribute should only have read access and be set by
the Context constructor, which should then also call set_defaults,
which then does not have to be in the API.

Ceriel