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.