- From: Arun Ranganathan <arun@mozilla.com>
- Date: Sun, 15 May 2011 16:37:30 -0400
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>, Mark Nottingham <mnot@mnot.net>
On 5/14/11 5:51 PM, Noah Mendelsohn wrote: > FYI, from the uri@w3.org mailing list. Discussion should be held > there, I think, at least for now. Thank you, Noah! Much of the discussion of the actual FileAPI takes place on public-webapps@w3.org so if you or the TAG have material feedback on the actual API, that's the preferred discussion list. But as far as discussion of the URI scheme goes, I'm happy with it taking place here on the URI listserv. -- A* > > Noah > > -------- Original Message -------- > Subject: Discussion of Blob URI Scheme for Binary Data Access | IETF > Resent-Date: Fri, 13 May 2011 18:09:08 +0000 > Resent-From: uri@w3.org > Date: Fri, 13 May 2011 14:05:39 -0400 > From: Arun Ranganathan <arun@mozilla.com> > Reply-To: arun@mozilla.com > Organization: Mozilla Corporation > To: uri@w3.org > > Greetings URI listserv! > > I'm writing to this listserv at the behest of Mark Nottingham, who sent > me here from the ietf-http-wg@w3.org listserv. This email is about a > "new" URI scheme used to access binary data, and we'd like feedback on > it, as well as advice on whether any further standardization endeavors > are necessary. > > My name is Arun Ranganathan, and I'm the current editor of the File API > [1] specification (sometimes called the HTML5 File API, which is > unfortunate); I'm also the former Chair of the WebGL Working Group [2] > (which brings hardware-accelerated 3D graphics to the web), and have a > continued interest in allowing binary data to be securely accessed and > manipulated on the web. I'm sponsored by Mozilla. > > The File API introduces the notion of a Blob object [3], which > represents immutable binary data. A file from the underlying file > system can be asynchronously read as a Blob object into various data > formats, for example. The existing File interface in JavaScript > inherits from Blob. > > Additionally, and most significantly for this listserv and this > discussion, the File API introduces a URI scheme for Blob access [4]. > The URI scheme uses a subset of the HTTP status codes, and is designed > to be used wherever http URIs can be used within HTML markup and within > APIs in JavaScript (e.g. for "img src =", alongside XMLHttpRequest, > etc.). The nascent URL API [5] which coins and revokes blob: URIs is > also used with the Stream API [6] for video-conferencing use cases, and > thus this scheme is becoming integral to emerging technologies under the > broad aegis of HTML. > > Browsers such as Chrome already implement blob: URIs [7]; Firefox's > implementation will follow-suit, although is likely to be > vendor-prefixed. Our goals are to address the shortcomings of the > file:/// URI scheme, which many browsers support for directory browsing > of the underlying file system, but for little else (file:/// URIs are > unwise choices for APIs like XMLHttpRequest, don't supply response > codes, etc.). The blob: scheme was designed to address the use case of > dereferencing files and binary data on the web safely, since data: URIs > have shortcomings as well, and can't really be used for streams of data. > > We'd welcome your feedback, including suggestions about whether > embarking upon an IETF standardization track for this protocol is > necessary. The File API will soon be initiating a CFC for Last Call > status. > > -- A* > > [1] File API: http://dev.w3.org/2006/webapi/FileAPI/ > [2] WebGL: http://www.khronos.org/webgl/ > [3] Blob defintion: http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob > [4] blob: URI scheme: http://dev.w3.org/2006/webapi/FileAPI/#url > [5] URL API: http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking > [6] Stream API: > http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#stream-api > > > [7] Use of blob: URI scheme in demos: > http://www.html5rocks.com/tutorials/workers/basics/#toc-inlineworkers-bloburis > > > >
Received on Sunday, 15 May 2011 20:38:04 UTC