[SAGA-RG] Context and Session thoughts

[Andre Merzky]

Hi Steve, 

Quoting [Steve Fisher] (Feb 19 2009):
> 
> 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. 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.
> 
> An implementation (which may or may be adapter based) has a set of
> contexts that it knows about - each with an implementation-defined
> type.

Not that for a single (impl defined) context type, multiple
default contexts may exist.


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

No, not really.  A default context is a context which can be
established by the implementation without any user
intervention.  As such, it has a full set of attributes.

For example, a globus adaptor may implement the detection of
two default contexts.  For the first one, it may set
UserProxy to the value of the applications X509_PROXY env
variable, for the second one it may set UserProxy to
/tmp/x509_<uid> with the applications running user id uid.

That way, the saga objects in the default session can
perform operations on the globus backend with either one of
these contexts (assumed that they are valid, and differ).

What context type is supported by the adaptor ('globus'),
and what information are used to find default contexts
(environment, default file location + uid) need to be
documented by the implementation.  Anyway, those contexts
get attached to the default session.


BTW: 

  saga::context c ('globus');
  c.set_defaults  ();

will yield one of the default globus contexts - which one is
up to the implementation.  In general, I assume that one set
of adaptors will provide one default context - the above
example is somewhat arbitrary, but hopefully illustrates
things.


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

Default contexts do not _need_ to be modified by the end
user.  OTOH, users _can_ modify them, to change parameters.
As an example:


  saga::context c ('globus');
  c.set_defaults  ();
  c.set_attribute ("LifeTime", "30");

would set the lifetime of a default globus context to 30
seconds (or whatever).  I doubt that this is a useful
scenario, but you get the idea.  Basically, you can create a
default context, and derive a customized one.


> 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 c'tor is, by definition, not setting attributes (apart
from the given 'Type'.  Otherwise, your description above is
correct: the user creates a context with a type known to him
and to the implementation, and then likely needs to set
attributes in order to obtain a useful context.


> The set_defaults call should *not* be in the spec - it is purely an
> implementation thing.

Sorry, I disagree: it is supposed to take the burden from
the end user to know what default can be set.  It has
nothing to do with the creation of default contexts for the
default session: that is completely done in the background,
within the implementation.  You could consider
'set_defaults' as a way to sensibly initialize a context's
attributes.

Hope that helps, 

  Andre.


> Steve

-- 
Nothing is ever easy.