<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Refactor AudioContext implementation to enable automatic binding generation of promise-based methods"
href="https://bugs.webkit.org/show_bug.cgi?id=145223">145223</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Refactor AudioContext implementation to enable automatic binding generation of promise-based methods
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>528+ (Nightly build)
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>WebCore Misc.
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>youennf@gmail.com
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>