- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 20 Jun 2013 14:33:26 +0200
- To: public-webrtc@w3.org
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. That's what the queue was supposed to accomplish: Making sure the outcome is deterministic, no matter how stupidly the operations were fired.
Received on Thursday, 20 June 2013 12:33:59 UTC