[SAGA-RG] Context and Session thoughts

[Ceriel Jacobs]

Andre Merzky wrote:
> Quoting [Ceriel Jacobs] (Feb 25 2009):
>> Andre Merzky wrote:
>>> Quoting [Ceriel Jacobs] (Feb 25 2009):
>>>> 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, true, the exceptions listed on set_defaults are almost
> always listed on other API calls, too (almost though -
> IncorrectState may be the exception).  

Yes, but that one is only thrown if the context has an empty Type,
which should not be a default, I think.

> So, lets try a similar use case to before:
> 
>   1  saga::context c1 ("ssh");
>   2  saga::context c2 ("myproxy");
>   3  c2.set_attribute ("Server", "myproxy.teragrid.org/does-not-exist");
>   4
>   5  saga::session s;
>   6  s.add_context (c1);
>   7  s.add_context (c2);
>   8
>   9  saga::file f (s, "ssh://dead-host.net/data/file");
>  10  f.copy ("gridftp://qb.teragrid.org/etc/passwd");
> 
> Line 10 would then stumble over the fact that the server I
> specified for the context does not exist.  And an
> AuthenticationDenied exception would actually fit
> semantically, too.  I agree so far with you.  
> 
> What I don't see is why you have a problem with having
> set_defaults in the API, as a fixed point to check for that
> error. 

I am having a (small) problem with that because
set_defaults() cannot always check that there actually
is an error, because it is the context, in combination with
the specific server, which determines if there is an error
or not. I can see some, but limited, usefulness in some call
to check a context in itself, but set_defaults suggests something
else which could just as well (and IS in the SAGA 1.0 specs)
be done in the constructor.

> Naively, the user could also expect it to get raised
> on the lines 3, 7, or 9.  The calls on line 3 and 7 don't
> have AuthenticationDenied exception defined.  The call on
> line 9 is not obviously connected to the teragrid.  In
> particular on line 9, the engine may try the myproxy context
> first, and would raise the misleading AuthenticationDenied
> exception (*).
> 
> Also, set_defaults, as motivated earlier, has other uses,
> too - so it is not like it is going away, really:
> 
>   saga::context c ("globus");
> 
>   c.set_defaults ();
> 
>   // get info about default globus proxy
>   std::cout << c.get_attribute ("LifeTime");
>   std::cout << c.get_attribute ("UserID");
>   std::cout << c.get_attribute ("VO");
> 
> without set_defaults, it is totally undefined when these
> attributes are available.

After calling the constructor? As would be the case for
the SAGA 1.0 specs?

  > One can very likely achieve a consistent API w/o
> set_defaults, by defining a couple of semantic changes which
> address the issues above explicitely, no doubt.  I just
> don't think (a) that this is justified, and (b) that this
> would really simplify matters.

But I think the CURRENT changes with respect to SAGA 1.0 are
much bigger.

O well, I think I have vented my opinion enough for now ...

Ceriel