[Webkit-unassigned] [Bug 145223] New: Refactor AudioContext implementation to enable automatic binding generation of promise-based methods
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed May 20 14:14:19 PDT 2015
https://bugs.webkit.org/show_bug.cgi?id=145223
Bug ID: 145223
Summary: Refactor AudioContext implementation to enable
automatic binding generation of promise-based methods
Classification: Unclassified
Product: WebKit
Version: 528+ (Nightly build)
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: WebCore Misc.
Assignee: webkit-unassigned at lists.webkit.org
Reporter: youennf at gmail.com
It would be good to have automatic generation of binding code for promise-based APIs.
A first step might be to refactor existing promise based APIs such as AudioContext, getUserMedia or ReadableStreamReader to align the custom binding code with what would be automatically generated.
I can see 3 approaches:
- Making resolve/reject promise callbacks take a single parameter, passed to the DeferredWrapper without any change.
- Beef-up the IDL promise to type the reject/resolve promise values
- Bite the bullet and make DeferredWrapper a first class citizen of WebCore (maybe renaming it then?). Use directly its API and remove callbacks, at least at binding level.
Option 1 is the natural step given the current code since DeferredWrapper is currently contained to custom binding code.
Option 2 is similar to option 1, a bit more complex at code generation probably, and extending the IDL language.
It would allow having better callback prototypes, like callbacks taking no parameters (or several) for instance.
Option 3 is probably the way to go in the end.
The binding code would be straightforward.
It would handle more nicely rejection of promise with different types (like exceptions or specific application values).
We would no longer be restricted by resolve/reject overloading rules (current reject(int) probably means reject(ExceptionCode)).
The downsides of option 3 compared to callback-based APIs is that callbacks are probably more reusable.
This may be useful (highly speculative) when implementing ReadableStream/MSE link for instance.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150520/ea4d52d7/attachment.html>
More information about the webkit-unassigned
mailing list