Re: crypto-ISSUE-24: Defining a Synchronous API [Web Cryptography API]

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 oncomplete?

> 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).

> 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.

-- A*

Received on Tuesday, 21 August 2012 19:06:18 UTC