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

[Andre Merzky]

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



-- 
Nothing is ever easy.