- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Thu, 18 Apr 2013 17:05:02 +0200
- To: public-webapps@w3.org
- CC: Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Ben Turner <bent@mozilla.com>, Alex Russell <slightlyoff@google.com>
On 15/04/13 12:50, Anne van Kesteren wrote: >> So I guess the current solution is fine as longs as either >> * No JS libraries will want to implement APIs that uses locks, or >> * Such libraries are ok with not using the built-in Future API and >> instead re-implementing the Future API themselves. > > The problem with exposing this directly is that you can also do bad stuff. What kind of bad stuff? There is nothing that the content will magically be able to do and wouldn't be able to do before. Also, this would force content to write their own Future implementation to workaround this limitation which is I believe the opposite intent of specifying Futures in the DOM specification. Given the IndexedDB use case, it seems to me that adding an optional synchronousFlag parameter to the methods in FutureResolver is worth it. Cheers, -- Mounir
Received on Thursday, 18 April 2013 15:05:29 UTC