- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 20 Aug 2012 18:43:55 +0000
- To: Ryan Sleevi <sleevi@google.com>
- CC: Web Cryptography Working Group <public-webcrypto@w3.org>
On Aug 20, 2012, at 11:17 AM, Ryan Sleevi wrote: > On Mon, Aug 20, 2012 at 9:09 AM, Mark Watson <watsonm@netflix.com> 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. >> >> 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. > > Did you mean CryptoOperation.complete()? > > I'm pretty disinclined to expose a sync method on a non-worker > context, since I think in practice it'll end up pretty heavily abused. > As both David and I can attest to, I think there's pretty strong > opposition to providing sync, blocking methods in new HTML APIs > outside of a worker context. This is akin to FileReaderSync only being > usable on WorkerContext. > What about onclose handlers ? This is an example of a non-worker context where synchronous methods are needed. Unless there is some way to ensure the events do get processed after the onclose handler completes (which would be cleaner). But anyway, my point was mainly that you don't have to re-design the API to make a synchronous version. If you want more separation, you could have a common base class with the existing methods and attributes (except complete()) and then subclasses for the synchronous (with a wait() method) and asynchronous (with the complete() method) versions. …Mark > >> >> 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 ?). >> >> …Mark >> >> >> On Aug 20, 2012, at 7:45 AM, Web Cryptography Working Group Issue Tracker wrote: >> >>> crypto-ISSUE-24: Defining a Synchronous API [Web Cryptography API] >>> >>> http://www.w3.org/2012/webcrypto/track/issues/24 >>> >>> Raised by: Ryan Sleevi >>> On product: Web Cryptography API >>> >>> In v1.15, the Web Crypto API still makes heavy use of special interface-objects in order to provide asynchronous implementations of methods such as encrypting, hashing, or generating keys. >>> >>> However, in nearly every major cryptography API, these operations are all synchronous, and thus user agents will be forced to simulate an asynchronous API atop a synchronous API. >>> >>> Does it make more sense to define the Web Crypto API as a *purely* synchronous API, but which can *only* be accessed from Web Workers? >>> >>> This effectively leaves the asynchronous semantics up to applications to implement, by forcing them to use web workers. However, it allows the exposed surface of the API to be significantly reduced, as well as easier specification of the state machines. >>> >>> A "complementary" synchronous API, as has been expressed as desired, is more likely a complete rethinking and re-implementation of the API. >>> >>> This is, to some degree, also related to ISSUE-18, since exposing cryptographic transforms via the various proposed streaming APIs also implies asynchronicity, but with a more consistent programming model to existing web platform APIs. >>> >>> >>> >>> >> >> >
Received on Monday, 20 August 2012 18:44:24 UTC