- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 20 Jun 2013 14:44:26 +0200
- 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