Sounds reasonable. Thanks, Andre. Quoting [Sylvain Reynaud] (Sep 29 2009):
Dear Andre,
OK for leaving that to a later version.
Until this later version, we will probably keep our non-standard flag, but also warn the users that it breaks application portability and propose asynchronous calls as an alternative.
Cheers, Sylvain
Andre Merzky a écrit :
Dear Sylvain,
About the DelayError flag: could we leave that to a later version of the API? My impression is that
- the problem affects a rather small number of use cases - the problem is (at least partially) solved by async calls - the solution implies significant semantic changes, like state changes for ns_entries, limited ability to retrieve the complete error, etc. - the solution picks a very specific call (open) to delay errors, but ignores the same problem on other calls
I think I understand the problem you are trying to solve by now, but I'd suggest not to use a stopgap solution.
Its a pity that others did not utter any preferences - that would make it easier to estimate how important people think this is... Anyway, I'll certainy try to get some feedback from people at OGF27.
Cheers, Andre.
Quoting [Sylvain Reynaud] (Sep 24 2009):
Date: Thu, 24 Sep 2009 17:11:46 +0200 From: Sylvain Reynaud
To: Andre Merzky CC: Thilo Kielmann , saga-rg@ogf.org Subject: Re: [SAGA-RG] missing(?) method reporting last modification time Andre Merzky a écrit :
Quoting [Sylvain Reynaud] (Sep 24 2009):
Is your use case different from those cases where one could delay error reporting, too? If so, how?
Or positively speaking:
If there is a reason why async operations won't work,
It would work, but it is still useless messages sent to the server...
Ah, ok - but then we are talking about bandwidth, and fairly small bandwidth, too.
One use-case for this is a demo from a laptop in a conference for example.
But then again, introducing a general flag for delaying errors is quite a significant semantic change, really. FWIW, Hartmut (and someone else, can't remember) brought that topic up a while ago, when wondering if SAGA calls should not be getting an optional additional parameter to be returned on any errors, like
// standard SAGA call size_t s = file.get_size (); // can throw std::cout << "size: " << s << "\n";
// error ignoring SAGA call size_t s = file.get_size (0); // never throws if ( s == 0 ) std::cout << "size: Unknown\n;"
The proposed signature change would basically allow for SAGA calls which never throw, no matter the error condition.
I don't see any reason for doing this, since the user can always catch the exception if he/she wants to ignore the error.
Well, the same can be said for your use case. The reason is caching, and delayed execution. The example above may be misleading, I agree. But consider a file.open(), or file.copy(), which basically has the same semantics as the file constructor.
Yes, file.open() has exactly the same semantics and would need the same flag. But file.copy() generally detects errors with no extra communication.
What I would like to do is not to ignore errors that have already been detected, but to disable preliminary checks when needed.
It depends on the use case which checks are preliminary. For your UC it is file existence. For another use case it may be file read permissions. Yet another UC may be job submission permission. Or if a stream can in fact connect to a port. Or if an RPC endpoint really exists and can be used. These are all checks which are implied for various SAGA object constructors...
That is why I am hesitant to add it do the spec, and then describe the flag as 'don't check for file existence', because someone else will come and ask for a different check to be disabled for sure. Bottomless pit ;-)
'DelayErrors' includes them all at least for namespace entries. Other packages do not have flags anyway.
Bottom line: An IgnoreDoesNotExistException (which your 'MissingOK' basically translates to) sounds a very specific flag, for a very specific use case. Do asynchronous operations help?
Better than synchronous, but still not optimal...
If not, should we consider a DelayErrors flag, possibly for the next SAGA version?
'DelayErrors' sounds good to me.
Ok, great - then lets stick to that name. But I'd rather move that to the next version, unless it is a no-go for you.
I guess some JSAGA users will probably prefer to continue using my non-standard flag rather than using asynchronous method, but I think the compatibility break is not so big if SAGA implementations can just ignore non-standard flags... unless both of them have non-standard flags of course...
Cheers, Sylvain
Any opinion from the others?
Cheers, Andre.
-- Nothing is ever easy.