Re: Summary of desired spec updates (Was: summary of some ongoing discussions)

On 07/17/2012 04:38 PM, Stefan Hakansson LK wrote:
> On 07/16/2012 08:45 PM, Justin Uberti wrote:
>> I've tried to summarize all of these changes and the discussions of the
>>   past few weeks into a concrete proposal for an updated API. This
>> proposal is attached, and is also available at
>> https://docs.google.com/document/d/1nfA1ElWed5PPR4nqenEkxNMMLRfzAsh1yMLe8yRcns8/edit#. 
>>
>
> Justin, thanks for the input. I appreciate concrete proposals on how 
> to solve issues we have identified!
>
> Personally I think what you propose seem to make sense. Some things 
> have not been discussed that much yet, but I would be fine if they 
> were included in the Editor's draft (which of course can change based 
> on the discussions).
>
> The only thing that I immediately think could perhaps have another 
> solution is the async callback to setLocal/setRemote. I think what we 
> want to accomplish is a way to handle errors (you are not going to do 
> anything on the success callback, right?), and perhaps we should have 
> a more generic error reporting mechanism. That said, I have no problem 
> using the async callback in the Editor's draft (if there is need to 
> specify a way for error reporting) for the time being.

The thing about a success callback is that it allows you to know 
specifically that you won't get an error callback later, so that (for 
instance) you can remove the UI components that would display this 
particular type of error.

There have been systems before that did RPCs with just an error return 
(silent success) or just a success return (silent error); they proved 
very confusing to use, and were not popular.

If an app really doesn't care about one of the callbacks, it can just 
not provide any handler for that callback. I think that is flexibility 
enough.

                   Harald

Received on Wednesday, 18 July 2012 13:19:22 UTC