Re: Discussion of Blob URI Scheme for Binary Data Access | IETF

As the author of dynamic compilers, standardization is easier if there 
is interchange of JavaScript into intermediate language or XML flow.

I assume you meant "desired" immutable data, yet is there any 
constraint? (Not even XPath?) The reasons are more obvious if the http 
query *has to* specifically request javascript for acceptable response 
rather then the webserver present that by default. The "User-Agent:" 
field allows workaround for now. By default, the web-server "shouldn't" 
allow just any script (botnet) be server-pushed or server-solicited. 
Web-servers can't just trash the <script> tags.

However, this inspired me to say maybe the "User-Agent:" could be set to 
"urn:..." as the intermediate implementation such that vendors can apply 
security updates quicker. I assumed people aren't gonna to update their 
web-server software (too costly. i.e. hardware as in "farms"), yet they 
can update their plug-in modules less expensively (seeds).

Economy wise, if "User-Agent:" is set to "urn:..." then certificates 
make sense for cache. No certificate, no cache.

Is that deal better for... blob?

On 05/12/2011 01:02 PM, Arun Ranganathan wrote:
> Greetings httpbis listserv!
>
> My name is Arun Ranganathan, and I'm the current editor of the File 
> API [1] specification; I'm also the outgoing 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 working group, 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 on the web.  The nascent URL API [5] which 
> coins and revokes blob: URIs is also used with the Stream API [6] for 
> video-conferencing use cases.
>
> 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 choises for APIs like XMLHttpRequest, don't supply 
> response codes, etc. 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 embarking upon 
> an IETF standardization track for this protocol.
>
> -- 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 
>
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

Received on Thursday, 12 May 2011 22:32:00 UTC