[SAGA-RG] missing(?) method reporting last modification time

[Sylvain Reynaud]

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.
>
>
>