[SAGA-RG] Context and Session thoughts
Andre Merzky
andre at merzky.net
Wed Feb 25 03:56:38 CST 2009
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.
More information about the saga-rg
mailing list