Andre Merzky wrote:
Quoting [Ceriel Jacobs] (Feb 25 2009):
Andre Merzky wrote:
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
Quoting [Ceriel Jacobs] (Feb 25 2009): 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