[SAGA-RG] Context and Session thoughts

[Ceriel Jacobs]

Andre Merzky wrote:
> Quoting [Ceriel Jacobs] (Feb 25 2009):
>> Andre Merzky wrote:
>>> Quoting [Ceriel Jacobs] (Feb 20 2009):
>> (who quoted Steve Fisher)
>>>>> 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  ();
>> Well, calling set_defaults in the constructor IS in the specs, at least
>> it is in the 1.0 version, which is still the official version, is it not?
>> There, it sais in the Notes: if a type is given, then the CONSTRUCTOR
>> internally calls set_defaults().
> 
> Right - the errata remove that call.
> 
> 
>>> 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? 
>> I don't know that the c'tor would throw NoSuccess. Maybe a default
>> UserProxy file does not exist, but is set_defaults() the right
>> time to check? 
> 
> When else can you check?  On setting the attribute would be
> an option - but throwing there would confuse: the exceptions
> defined on set_attribute are attribute related, not related
> to the semantics of the context.  One could also check
> internally at the first time the context is being used, but
> then it is hard to predict on API level when that exception
> will come, and again it is probably in a context unrelated
> to the, uhm, context (pun unintented).  So, set_defaults
> provides a good opportnity to flag any inconsistencies.

I would indeed check the first time the context is being used.
I don't think it is hard to predict on API level when an exception
will come, because virtually all methods can throw a
corresponding exception. Also, set_defaults may possibly detect
SOME inconsistencies, but certainly not all.

>>> 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?
>> I guess there is a difference between "" and "klopus" in that
>> "" is IMHO supposed to mean that the Type is not yet specified,
>> whereas "klopus" specifies a Type, on which the constructor
>> will call set_defaults(), which will probably cause an exception.
> 
> Again, set_defaults() in the c'tor cannot work - you could
> never create a context with a non-default location for the
> globus proxy file.  

Indeed, not if you want set_defaults to do all the things you
describe. But I don't think set_defaults is the right place.
If you set some attributes explicitly, like "UserProxy",
or "UserId", or "UserPass", there is no check either. In general,
the first time you notice that something is wrong is when you
try to actually use the context. I don't see why this should be
any different if you use set_defaults. For instance, you could
create an ftp context with perfectly reasonable default values
for UserId and UserPass, but if you then connect to an ftp server
that does not allow anonymous access, you still have a problem.
So, I think a cleaner design would be to not have set_defaults,
and to have the context constructor set some reasonable default values
(if a Type is specified). It would then be up to the user to make sure
that the default values actually work.

Cheers,		Ceriel