- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 21 Aug 2012 12:24:22 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: Arun Ranganathan <arun@mozilla.com>, Web Cryptography Working Group <public-webcrypto@w3.org>
On Tue, Aug 21, 2012 at 12:21 PM, Mark Watson <watsonm@netflix.com> wrote: > > On Aug 21, 2012, at 12:05 PM, Arun Ranganathan wrote: > >> >> On Aug 20, 2012, at 12:09 PM, Mark Watson wrote: >> >>> We were thinking about this also, since a synchronous API is needed to use WebCrypto in onclose handlers, where the event loop is stopped immediately you exit the handler. >> >> >> I'm not sure exactly why you say that a synchronous API is needed for onclose handlers. Can you give an example of this type of usage in pseudo-code? Do you mean onabort or incomplete? > > I mean the thing that is called when the user closes the browser window. I think that's onclose on the window. > > If you want to use WebCrypto in that context, it needs to be synchronous, because after that handler exists no more JS is processed (tasks put in the queue by virtue of the things you did during the handler are not executed IIUC). It has been proposed and supported by a number of browser vendors to remove the ability for script to perform synchronous actions during unload, including the use of modal dialogs and the like. This is a significantly negative user experience. Thus, I think this use case is a hard sell, amongst all the possible use cases for a synchronous API :) > >> >> >> >>> >>> The existing API could be given a synchronous mode just by adding a boolean, "synchronous" to the close() method of CryptoOperation. If true, the close call would block until the operation was complete. Events would not be generated and the application would determine the outcome by inspecting the CryptoOperation attributes. >> >> >> It is possible to do this, but I'm not sure it's advisable. XMLHttpRequest allows for a synchronous mode as well as an asynchronous mode, but I think that most developers use it asynchronously, for fear of blocking the main thread. >> >> And this is definitely true of the File API. Blocking on the main thread is undesirable, so synchronous operations are only allowed on threads (e.g. FileReaderSync). > > Yep, synchronous calls should only be used in workers, or when absolutely necessary (onclose handlers). > >> >> >>> I'm not sure about requiring Web Workers. Everyone will need asynchronous versions, since these operations may take some time on some platforms (for example if the crypto is being done on a smartcard or similar). It doesn't seem a good idea to make everyone re-implement the same Web Workers wrapper. It also brings in Web Workers as an additional dependency for using this API and I am not sure they are universally available (on TVs for example ?). >>> >> >> >> I think WebWorkers should be considered an integral part of The Platform. It's hard to do sophisticated web applications without them, and I think it's a fairly safe bet to conclude that they'll be part of future JS environments. A dependency on HTML5 is just about tantamount to a dependency on WebWorkers anyway. > > My worry is that the "just about" in that statement is enough to cause cost-concious TV manufacturers working on constrained platforms to decide that WebWorkers are not needed until the next release (or the one after that …) > > …Mark > >> >> -- A* >> >> > >
Received on Tuesday, 21 August 2012 19:24:53 UTC