[Webkit-unassigned] [Bug 145223] New: Refactor AudioContext implementation to enable automatic binding generation of promise-based methods

[bugzilla-daemon at webkit.org]

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>