W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Operations in invalid states: Exceptions don't make sense.

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 20 Jun 2013 14:44:26 +0200
Message-ID: <51C2F92A.5090702@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: public-webrtc@w3.org
On 2013-06-20 14:33, Harald Alvestrand wrote:
> On 06/20/2013 10:50 AM, Adam Bergkvist wrote:
>> On 2013-06-19 18:28, Jan-Ivar Bruaroey wrote:
>>> On 6/19/13 2:47 AM, Adam Bergkvist wrote:
>>>> With a processing state, the second call would always fail.
>>>
>>> Agreed.
>>>
>>>> That's deterministic and observable from JS (compared to a queue in
>>>> the background).
>>>
>>> The current approach is also deterministic, as I showed.
>>> The current approach is also observable from JS because the failure
>>> callback is called. In fact with Futures/Promises, there's little
>>> difference.
>>
>> With Future/Promises you practically build the operations queue in
>> your application; that's rather nice and what I think is desirable.
>
> I think that's hoping for too much.
>
> Using Promises may make it easy to sequence one chain of operations.
> It does not give any protection against (deliberately, maliciously or
> accidentally) firing off multiple chains of operation that happen to
> interleave.

Sure, I was rather referring to the "easy to chain" properties of 
Futures/Promises. To protect against, as you call them, multiple chains, 
that's what a proper state machine is perfect for.

> That's what the queue was supposed to accomplish: Making sure the
> outcome is deterministic, no matter how stupidly the operations were fired.

Yes, but we can accomplish this without inventing something new.

/Adam
Received on Thursday, 20 June 2013 12:45:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC