[w3c/FileAPI] Async factory methods for Blob and File (#157)

`Blob` and `File` objects are currently created using the [Blob constructor](https://w3c.github.io/FileAPI/#dom-blob-blob) and [File constructor](https://w3c.github.io/FileAPI/#dom-file-file). While this is very intuitive, the synchronous aspect of the creation makes it difficult to integrate these object with modern storage systems.

**Motivation**

Here are two concrete problems I'm trying to address.

1) I would like Blobs and Files to be quota-managed. This means we'd charge them against the origin's quota, and error out if creating a Blob / File would drive the origin out of quota. In Chrome, computing the origin's quota usage is an expensive operation the first time we do it, so having to do it synchronously during Blob / File creation would be quite unfortunate.

Background: In Chrome, Blobs and Files objects can store more data than would fit in RAM. This is accomplished by spilling the content to disk when needed. Since they write to disk

2) In Chrome, Blobs and Files need to be registered in a browser-global registry, in order to serve requests to `blob://` URLs. This is currently done by invoking a synchronous IPC in the `Blob` and `File` constructors. 

Alternative: This problem might also be addressed by migrating to an asynchronous flavor of [URL.createObjectURL()](https://w3c.github.io/FileAPI/#dfn-createObjectURL), and having Blobs and Files added to the registry on-demand. I think this leads to more implementation complexity, and doesn't address the desire of charging Blobs and Files against quota.

**Proposed solution**

Let's add `create` factory methods to `Blob` and `File`. The factor methods will take the same parameters as the corresponding constructors, and will return `Promise<Blob>` and `Promise<File>`.

```javascript
const blob = await Blob.create(["Message text."], { type: "text/plain" });
const file = await File.create(
    ["Attachment data"], "attachment.txt",
    { type: "text/plain", lastModified: Date.now() });
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/157