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

[Andre Merzky]

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.