936903 - Proposal of path-based blob-url and API: bindObject and onrequest

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, enhancement)

Description

[Duan Yao]

(sorry for the lengthy description, I just want to make my idea clear)

Current blob-url format and APIs (URL.createObjectURL/revokeObjectURL) have a few limitations which make development of certain types of webapp painful:

1. Blob-url is uuid-based, rather than path-based.

Path-based url can be referenced as relative url, which is very useful for documents which reference each other. Howerver uuid-based url does not support relative url.

For example, I am developing an epub editing webapp. An epub file is an zip archive that may contain html, css, image files, and these files reference each other via relative urls. My app unzip an epub archive, and create blob-urls for each files in it, and those relative urls have to be replaced by blob-urls or they are broken. Howerver, this procedue is tedious and error-prone. Even worse, the new Epub 3 format support javascript which may also use relative urls, and virtually make it not possible to replace all the relative urls by blob-urls.

2. The blob bound to the blob-url can not be created on demond, and reclaimed automatically.

In some situations, a blob-url is not dereferenced in its life time, or not dereferenced immediately, or not needed anymore. However the corresponding blob must be created and persists, and consumes CPU and memory.

In my epub editing app, I have to create blobs for all files in the epub before the first page can be rendered, even if they are not all acturally used immediately; after a page is unloaded, I can't revoke blob-urls it used because some of them may be used by other pages.

May be I could analysis the html and css to figure out urls acturally needed, but again, this is tedious and error-prone, and not possible when js is taken into account.

==========================================================================

In order to resolve the problems mentioned above, I propose a new blob-url format and two new APIs on URL object.

1. Path-base blob-url format
It looks like:

blob:/path/to/some/file

That is, a virtual path following the blob scheme. 
Now, blobs associated to path-base blob-urls can reference each other by relative url.

2. An method on URL object to bind a blob to a path-based blob-url

DOMString bindObject(DOMString pathOrUrl, Blob blob);

The parameter pathOrUrl may be full blob-url, or only the path portion;
the returned value is the full path-based blob-url. If the specified url has already been bound, this method rebound it with the new blob. 

The bound url could be revoked by URL.revokeObjectURL() if not needed.

This method is similar to URL.createObjectURL except that the resulting url can be specified by user.

3. An mechanism to return blob when corresponding blob-url is dereferenced

Add an callback property 'onrequest' to URL object:

RequestHandler onrequest;

callback RequestHandler = any (Request req, Response res);

interface Request {
  DOMString path; //the path portion of the requested blob-url
  optional Date lastModifiedDate; //the blob's modification time, similar to http If-Modified-Since header
  optional DOMString eTag; //the blob's eTag, similar to http Etag and If-None-Match header
}

interface Response {
  send(Blob blob); //send blob with default status(200)。
  send(Blob blob, Date lastModified); //send blob with modification time, similar to http Last-Modified header
  send(Blob blob, DOMString eTag); //send blob with modified time, similar to http Etag header
  send(Blob blob, unsigned short status); //send blob with status, usually 304 (not modified)，404 (not found), or 5XX (error). Blob is usually null here.
}

The initial value of URL.onrequest is null. 

When a path-based blob-url is dereferenced, if URL.onrequest is set, browser calls it with a Request object and a Response object to obtain the blob for that url. 

Whith the onrequest API, user code doesn't have to bind blobs to urls any more, just lazily create one (from database, by computation, or extract from zip archive) and send it until a url is dereferenced.

The blobs sent by Response are reclaimed automatically by browser (e.g. after the image has been rendered, css/js has been parsed), and user code should not care about it any more.

Browser may also decides to cache the obtained blob like it do with http. User code may send and check lastModifiedDate or eTag to optimize the cache.

Whith path-based blob-url and new APIs, I could develop my epub editing app much more easily: just map each file in an epub to an path-based blob-url deduced from its entry name, and all relative urls in it work automatically!