[SAGA-RG] missing(?) method reporting last modification time
Sylvain Reynaud
Sylvain.Reynaud at in2p3.fr
Thu Sep 24 10:11:46 CDT 2009
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.
>
>
>
More information about the saga-rg
mailing list