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

[Sylvain Reynaud]

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 <Sylvain.Reynaud at in2p3.fr>
>> To:      Andre Merzky <andre at merzky.net>
>> CC:      Thilo Kielmann <kielmann at cs.vu.nl>, saga-rg at 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.
>>>       
>
>