[SAGA-RG] Context and Session thoughts

[Steve Fisher]

Perhaps this is something we could discuss next week in Catania

2009/2/25 Ceriel Jacobs <ceriel at cs.vu.nl>:
> 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
>