[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