Quoting [Ceriel Jacobs] (Feb 20 2009):
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.
This indeed looks like a spec error to me. A user should NOT be able to change a context which is in use. That was the reson to require a deep copy on add_context. It seems to me that list_contexts should be symmetric, and also return deep copies. If you folx agree, I make this an errata.
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.
Calling set_defaults() in the c'tor breaks. That was actually in the spec at some point, but: saga::context c ("globus"); c.set_attribute ("UserProxy", "/tmp/non-default-proxy.x509"); c.set_defaults (); The c'tor would throw NoSuccess if no default globus proxy exists. Then, how would you create a globus context which points to a non-default proxy location, like above? Yes, one could argue if an empty type on context creation makes sense, or if one should mandate a valid string. Given that an empty string is a 'valid' string in most languages, that is not much different from other invalid strings like 'klopus'. We have defined error conditions for calling set_defaults() on invalid context attributes. I don't think that this is a big problem at the moment? Best, Andre. -- Nothing is ever easy.